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Partial  Fulfillment  of  the  Requirements  for  the  Degree  of  Doctor  of  Philosophy 

A DISTRIBUTED  IN-PROCESS  SUPERVISION  OF  MILLING  BASED  ON  SIGNAL 

PROCESSING  MACHINING  MODELS 

By 

Russell  Craig  Walters 
December  1993 

Chairman:  Jose  C.  Principe 

Major  Department:  Electrical  Engineering 

This  dissertation  examines  the  problem  of  supervising  milling  operations.  Milling  is 
an  important  field  of  manufacturing,  and  supervision  coupled  with  in  situ  sensors  will  pro- 
vide the  means  by  which  in-process  control  can  be  implemented. 

A model  is  developed  by  which  the  force  signal  in  steady-state,  multi-tooth  face 
milling  is  fully  described  based  on  the  force  of  each  individual  tooth.  The  single  tooth 
force  signal  model  has  been  heavily  researched,  so  the  multi-tooth  model  describes  the 
composite  signal  in  terms  of  what  is  known  from  the  physical  model  for  single  tooth  mill- 
ing. Furthennoie,  there  are  important  applications  of  this  model  in  terms  of  observation  of 
milling  features  and  extraction  of  parameters  of  cut.  Knowledge  obtained  from  this  analy- 
sis is  then  used  to  describe  the  events  resulting  from  tool  breakage  and  relate  feature  sizes 
to  known  physical  parameters.  A real-time  computer  algorithm  has  been  implemented 
based  on  these  principles  and  tested  with  milling  data. 

The  supervision  of  a machine  tool  is  modeled  as  a loosely  coupled  distributed  com- 
puter system.  This  system  integrates  event  detectors  into  a computationally  extensible 
architecture.  The  modeling  involves  an  object-oriented  hierarchy  for  supervision  functions 
temporally  ordered  through  threads.  In  this  research  a computer  numerical  controller 
(CNC)  was  integrated  with  a workstation,  a PC,  and  two  digital  signal  processors  (DSP). 

vii 


The  CNC  is  normally  an  autonomous  system.  Therefore,  an  interface  was  developed  that 
provides  the  CNC  as  a distributed  system  resource.  DSPs  are  used  to  provide  fast  process- 
ing of  sensor  data  to  provide  rapid  recognition  of  milling  events.  The  workstation  ties  the 
system  together  by  means  of  an  ethemet  communications  network  and  provides  a user 
interface  to  the  milling  operation.  An  off-line  data  analysis  tool  is  integrated  into  this  sys- 
tem for  testing  and  validation  of  algorithms. 


CHAPTER  1 
INTRODUCTION 


Manufacturing  Control 

Manufacturing  is  a material  transformation  process  that  produces  a desired  object 
both  in  terms  of  specific  geometry  and  internal  properties.  The  field  of  Flexible  Manufac- 
turing Systems  (FMS)  is  striving  for  overall  control  of  this  process.  Modeling  of  the  man- 
ufacturing system  is  needed  to  plan  and  control  the  process,  and  the  feedback  method  used 
for  control  specifies  the  degree  of  flexibility.  All  processes  are  subject  to  some  type  of 
feedback  control,  either  automatic  or  human-operated,  and  even  “no-control”  involves 
feedback  in  the  form  of  customer  complaints  or  warranty  recalls. 

If  we  consider  a process  time  constant  xp  that  defines  the  time  involved  in  complet- 
ing a process  and  the  feedback  delay  Td  that  defines  the  time  delay  necessary  for  a control 
method  to  update  the  process  parameters,  we  can  compare  various  methods  of  control. 
Table  1-1  illustrates  this  principle  [1], 


TABLE  1-1.  Classification  by  feedback  method. 


Feedback  Delay 

Control  Method 

Td  < 'tp 

Real-time  or  in-process 
control 

£ 

i! 

Iterative  control 

Td~  10-100  Xp 

Sampling  and  statistical 
process  control 

Tj-  103tp 

Empirical  modeling  and 
process  optimization 

Td  ~ months 

Warranty  recall 

Methods  of  process  optimization  [2],  statistical  sampling  [3],  and  iterative  control 
are  viable  solutions  for  large  batch  operations.  These  are  jobs  where  the  time  spent  in 
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optimizing  the  process  can  be  absorbed  by  the  large  number  of  identical  parts  that  are  pro- 
duced. However,  a goal  of  FMS  is  to  reduce  the  time  required  for  process  optimization  so 
that  small  batches  can  be  efficiently  produced.  This  flexibility  can  be  attained  through  in- 
process  control  where  a supervisory  system  would  modify  process  parameters  to  increase 
efficiency  as  well  as  detect  and/or  prevent  premature  failure. 

Flexible  Manufacturing  Systems 
FMS  can  be  decomposed  into  five  layers  [4]: 

• Device  Level:  This  is  the  lowest  level  in  the  hierarchy  and  consists  of  the  individual 
resources,  e.g.,  robots,  machine  tools,  sensors,  and  material  handling  systems. 

• Manufacturing  Cell  Level:  A manufacturing  cell  is  an  assembly  of  devices  that  are 
controlled  by  a common  computer. 

• Assembly  Line  Level:  An  assembly  line  consists  of  a number  of  interconnected 
manufacturing  cells. 

• Plant  Level:  This  level  manages  the  coordination  of  resources  and  jobs  in  the  plant. 

• Corporate  Level:  This  level  includes  global  process  planning,  production  manage- 
ment, financial  functions,  and  administrative  functions. 

The  focus  of  this  research  is  restricted  to  the  device  level,  which  is  the  first  level  that 
must  be  developed.  Signal  processing  models  are  presented  for  extracting  state  data  from 
sensors  as  well  as  a distributed  system  that  integrates  the  models  into  a real-time  supervi- 
sion system.  The  particular  system  examined  at  this  level  is  the  machine  tool.  Machining 
(turning,  milling,  drilling,  and  grinding)  has  been  at,  or  near,  the  top  of  the  lists  of  technol- 
ogies identified  as  critical  to  national  economic  competitiveness  and  security  in  recent 
studies.  Manufacturing  accounts  for  approximately  one  third  of  the  value  of  all  goods  and 
services  produced  in  industrial  nations.  Recognizing  the  critical  nature  of  manufacturing, 
much  research  has  been  directed  at  improving  efficiency.  However,  the  accomplishments 
of  the  early  research  had  not  solved  the  problems  but  clearly  indicated  the  complexity  of 
the  machining  system. 

Control  of  machine  tools  can  be  grouped  into  three  levels  (figure  1)  [5].  Servo  con- 
trol is  concerned  with  the  proper  position  of  the  axis.  Past  research  has  achieved  success  at 
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Supervisory  Control 
Process  Control 
Servo  Control 


Figure  1-1.  Hierarchy  of  machine  control. 


this  level  and  such  methodologies  have  successfully  migrated  into  commercial  applica- 
tions. Process  control  is  basically  the  control  of  tool  force.  To  increase  efficiency,  the  rate 
of  material  removal  is  adjusted  to  maintain  the  force  within  predefined  levels.  In  order  to 
minimize  the  probability  of  catastrophic  failures  such  as  tool  breakage,  metal  removal 
rates  must  be  kept  at  levels  that  will  not  produce  excessive  tool  force.  Without  a method  of 
in-process  control,  part  programs  must  be  calibrated  using  known  physical  models  and 
iterative  testing.  With  a method  of  control,  setup  time  for  the  operation  can  be  reduced  and 
conservative  material  removal  rates  need  not  be  used.  Although  much  research  has  been 
directed  toward  this  end  [6,7,8,9,10],  an  acceptable  commercial  implementation  has  not 
been  achieved.  Supervisory  control  includes  tool  breakage  monitoring,  chatter  detection, 
and  machine  monitoring.  This  control  level  is  also  used  to  adjust  parameters  for  strategies 
of  process  control. 


In-Process  Supervision  of  Milling 

Supervision  provides  a critical  observation  of  a system  that  is  used  to  give  proper 
direction.  This  relies  on  extracting  the  state  of  the  process,  which  requires  accurate  pro- 
cess models.  Since  realizable  sensors  do  not  normally  provide  critical  state  information 
but  are  partially  dependent  on  critical  state  information,  the  sensor  output  must  be  pro- 
cessed in  accordance  with  accurate  process  models  to  obtain  exactly  the  desired  informa- 
tion. Realizable  sensors  in  milling  include  spindle  displacement,  sound,  spindle  and  feed 
drive  current,  and  acoustic  emission  [11].  Critical  state  information  includes  individual 
tooth  force  and  workpiece  surface  quality. 
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Once  state  information  has  been  obtained,  decisions  can  be  made.  Catastrophic 
occurrences,  such  at  tool  breakage,  chatter,  and  excessive  spindle  torque,  require  immedi- 
ate and  automatic  intervention  by  the  supervisor.  Minimal  intervention  would  be  to  stop 
the  process  and  inform  the  operator.  More  sophisticated  methods  would  update  process 
parameters  without  operator  intervention.  State  information  can  also  be  used  for  monitor- 
ing. In  monitoring,  the  state  information  needs  to  be  converted  into  a medium  that  aids  an 
operator  in  visualizing  the  process  status.  Average  tool  force  would  be  an  example  of  a 
feature  that  one  may  desire  to  monitor. 

A supervision  system  is  only  as  good  as  its  underlying  machining  models.  For  this 
reason  the  creation  and  enhancement  of  machining  models  were  given  significant  empha- 
sis. Sound,  accurate  models  lead  to  well-defined  and  -understood  methods  of  control,  thus 
avoiding  ad  hoc  solutions.  Without  the  availability  of  models,  heuristic-based  routines 
need  to  be  used. 

Having  models  presents  the  possibility  of  decomposing  the  sensor  output  into  its 
constituent  parts.  An  example  of  decomposition  that  will  be  examined  is  the  extraction  of 
information  about  single  tooth  force  from  the  composite  force  signal  measured  in  multi- 
tooth milling.  Having  a model  for  the  construction  of  the  composite  signal  provides  the 
framework  for  developing  the  signal  processing  solution  for  feature  extraction. 

Milling  Force  Models 

Metal  cutting  can  be  described  as  a process  involving  friction,  plastic  flow,  and  frac- 
ture of  material  [12],  and  various  models  have  been  used  to  predict  its  forces.  Complex 
models  do  exist  that  attempt  to  define  the  physics  involved  in  material  removal,  but  these 
models  often  require  parameters  that  are  not  obtainable.  However,  simplified  models  have 
grown  to  gain  acceptance  as  reliable  predictors. 

In  chapter  2 the  evolution  of  the  force  model  is  presented.  The  contribution  of  that 
chapter  will  be  the  extension  of  the  force  model  to  include  the  effects  of  multi-tooth  mill- 
ing. The  force  signal  that  is  generally  available  in  multi-tooth  milling  is  a composite  signal 
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that  is  produced  by  the  force  from  several  teeth.  Since  algorithms  such  as  tool  breakage 
detection  measure  the  force  of  an  individual  tooth,  the  decomposition  of  the  multi-tooth 
signal  is  desirable.  It  will  be  shown  how  this  signal  is  constructed  and  that  the  single  tooth 
signal  is  only  partially  observable  in  multi-tooth  milling. 

Milling  Force  Measurement 

The  force  signal  is  not  easily  obtained  from  milling  machines,  and  various  methods 
have  been  used  to  find  an  estimate  of  the  force.  A review  of  sensors  for  machining  is  pre- 
sented in  the  paper  by  Delio  et  al.  [13].  Methods  of  acoustic  emission  have  been  used  to 
detect  the  high  frequency  signals  generated  by  the  fracture  of  material  on  the  workpiece 
and  tool.  However,  it  is  difficult  to  distinguish  tool  breakage  from  other  signals  and  noise. 
The  vibratory  nature  of  tooth  force  is  reflected  in  the  spindle  torque  oscillation.  By  using 
the  spindle  motor  current  as  an  estimate  of  torque,  an  estimate  of  the  force  can  be 
obtained.  However,  the  inertia  of  the  motor  acts  like  a low  pass  filter  with  a comer  around 
5 Hz.  The  current  of  the  feed  drive  motor  has  been  used  with  some  success  [14],  By  mod- 
eling the  friction  of  the  feed  drive  assembly,  a usable  bandwidth  of  400  Hz  was  produced. 
Table-type  dynamometers  are  also  restricted  to  the  lower  frequency  range  (300  Hz),  are 
difficult  to  build  into  the  structure  of  the  machine,  and  reduce  work  space.  Tool  force  is 
reflected  in  tool  and  spindle  displacement,  and  methods  of  measuring  spindle  displace- 
ment provide  reasonable  bandwidth  without  interfering  with  work  space.  This  has  led  to 
the  study  of  using  the  spindle  vibration  as  an  estimate  of  the  cutting  force  [15].  Proximity 
probes  can  be  mounted  in  the  stationary  spindle  housing  to  measure  the  distance  between 
the  probes  and  the  spindle.  A difficulty  common  to  all  of  these  methods  is  the  proximity  of 
the  sensor  to  the  teeth.  The  structure  between  the  cutting  process  and  the  teeth  will  filter 
and  distort  the  signal  according  to  the  transfer  function  between  the  cutting  process  and 
the  sensor  location.  Methods  of  direct  placement  of  sensors  show  promise.  Li  and  Li  [16] 
attached  a piezo  electric  film  to  a shim  located  behind  a tooth  insert.  This  approach  is  an 
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improvement  over  previous  attempts,  which  placed  the  sensor  directly  on  the  tooth  insert, 
in  that  the  shims  can  be  retained  whereas  the  teeth  are  disposable. 

The  CNC  Controller 

At  the  center  of  device  level  control  is  the  Numerical  Controller  (NC)  [17].  Numeri- 
cal Control  is  the  technique  of  giving  instructions  to  a machine  in  the  form  of  a code  that 
consists  of  numbers,  letters  of  the  alphabet,  punctuation  marks,  and  certain  other  symbols. 
The  machine  responds  to  this  coded  information  in  a precise  and  ordered  manner  to  carry 
out  various  machining  functions.  These  functions  may  range  from  the  positioning  of  the 
machine  spindle  relative  to  the  workpiece  to  controlling  the  speed  and  direction  of  spindle 
rotation,  tool  selection,  on/off  control  of  coolant  flow,  and  so  on. 

Instructions  are  supplied  to  the  machine  as  blocks  of  information.  A block  of  infor- 
mation is  a group  of  commands  that  enable  the  machine  to  carry  out  one  individual 
machining  operation.  For  example,  a block  of  information  may  command  the  machine  to 
move  the  work  table  to  a specific  coordinate  position,  or  set  speed  and  feed  values  to  carry 
out  the  machining  of  contours.  Each  block  is  given  a sequence  number  for  identification. 
The  blocks  are  then  executed  in  strict  numerical  order. 

A set  of  instructions  forms  an  NC  program.  When  the  instructions  are  organized  in  a 
logical  manner  they  direct  the  machine  tool  to  carry  out  a specific  task,  usually  the  com- 
plete machining  of  a workpiece  or  “part.”  It  is  thus  termed  a part  program.  Such  a part  pro- 
gram may  be  utilized,  at  a later  date,  to  produce  identical  results  over  and  over  again. 

Computer  Numerical  Control  (CNC)  [18]  retains  the  fundamental  concepts  of  NC 
but  utilizes  a dedicated  stored-program  computer  within  the  machine  control  unit.  CNC  is 
largely  the  result  of  technological  progress  in  microelectronics  (the  miniaturization  of 
electronic  components  and  circuitry),  rather  than  any  radical  departure  in  concept  of  NC. 

A CNC  machine  tool  has  many  advantages.  Having  a stored  program  allows  editing 
of  the  parts  program  to  be  done  at  the  machine.  Stored  sequences  or  “canned  sequences” 
that  are  common  in  machining  can  be  stored  permanently  in  the  CNC.  Subprograms  can 
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be  defined  for  repetitive  machining  sequences,  and  the  CNC  can  provide  communications 
facilities  to  communicate  with  other  computer-based  systems. 

With  the  integration  of  the  various  elements  of  a manufacturing  system,  communi- 
cation has  become  an  important  issue.  To  ensure  the  proper  function  of  all  the  elements  in 
an  integrated  manufacturing  system,  there  must  be  proper  communication  among  them 
[19].  The  specific  task  of  CNC  communications  is  addressed  in  chapter  5. 

Limitations  of  the  CNC  Controller 

Although  it  is  predicted  that  CNC  controller  hardware  will  move  toward  off-the- 
shelf,  general  purpose  computers  [20],  the  present  systems  are  composed  of  proprietary 
hardware  and  software.  The  method  of  system  integration  is  limited  by  the  system  not 
being  particularly  integration  friendly  [21].  Also,  the  CNC  hardware  for  this  project  is 
fixed.  Fortunately,  the  manufacturer  provided  for  software  extension  and  hardware 
options.  These  provisions  are  sufficient  to  provide  communication  and  external  supervi- 
sory control. 

The  CNC,  on  its  own,  does  not  monitor  the  effect  of  its  actions.  Careful  planning 
can  produce  an  NC  program  that  does  not  push  the  limits  of  the  milling  operation.  For 
large  batch  jobs,  where  many  identical  parts  will  be  produced,  the  time  spent  to  maximize 
the  efficiency  may  be  justifiable.  In  the  past,  various  respected  management  educators 
have  maintained  that  a business  has  four  dimensions  for  competing  in  the  marketplace: 
cost,  quality,  flexibility,  and  service.  A fifth  competitive  dimension  is  also  emerging:  speed 
of  new  product  introduction  or  time-based  competition  [22],  The  production  of  the  NC 
program  relies  on  the  knowledge  of  the  abilities  of  the  machine  based  on  the  material  of 
the  workpiece,  the  selection  of  the  tool,  and  the  complexity  of  the  cut.  During  real-time 
operations,  the  machinist  can  make  corrections  to  the  selections  of  feed  rates,  spindle 
speed,  and  depth  of  cut.  Tool  wear  and  variation  in  workpiece  material  can  cause  an  NC 
program  to  produce  nondesirable  results,  results  that  could  be  avoided  by  adjusting  feed 
rates  and  spindle  speed.  In  an  autonomous  machining  environment,  the  monitoring  system 
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Figure  1-2.  Parallel  structure  of  supervision. 


needs  to  make  these  corrections  if  the  planning  and  testing  stages  are  to  be  reduced.  This 
need  is  more  evident  in  small  batch  or  one-off  productions,  where  a lengthy  planning  stage 
is  not  economical. 

The  problem  of  multi-sensor  feedback  must  be  dealt  with.  Chapter  4 presents  a dis- 
tributed system  that  uses  several  independent  computers  to  deal  with  different  aspects  of 
machine  tool  monitoring.  Such  subsystems  could  include  tool  breakage,  chatter,  and  tool 
wear.  By  providing  separate  hardware  for  each  system,  the  hardware  can  be  specified 
according  to  the  requirements  to  complete  that  specific  task  within  the  required  amount  of 
time.  By  contrast,  in  a single-machine,  time-sharing  (multi-process)  system,  the  power  of 
the  computer  must  be  adequate  to  schedule  all  tasks  in  a timely  fashion.  With  many  of  the 
tasks  still  in  development  or  unspecified,  the  full  needs  of  a single  machine  cannot  be 
specified.  Figure  1-2  depicts  the  parallel  structure. 

The  use  of  autonomous  subsystems  will  provide  a scheme  for  incorporating  new 
monitoring  schemes.  However,  the  individual  schemes  are  not  fully  independent.  It  is  pos- 
sible that  the  decision  of  one  monitoring  scheme  can  be  overruled  or  modified  by  another 
scheme. 


Monitoring 

Machine  tool  monitoring  refers  to  measurement  of  sensor  data  from  the  milling 
machine  in  order  to  make  deterministic  evaluations  of  the  condition  of  the  cut.  The  need 
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for  monitoring  arises  from  the  variable  nature  of  machining.  That  is,  the  current  level  of 
machining  models  and  the  parameters  they  require  do  not  allow  for  precise  prediction  of 
the  machining  process.  Through  monitoring,  the  state  of  the  process  can  be  tracked,  which 
provides  the  possibility  of  adapting  the  process  parameters  to  changing  conditions.  Some 
of  the  various  monitoring  systems  that  are  commonly  studied  include  tool  breakage,  chat- 
ter, tool  wear,  and  torque  overload. 

A good  review  of  tool  wear  research  is  provided  by  Johnston  et  al.  [23],  and  Park 
and  Ulsoy  [24],  Research  in  tool  wear  is  generally  restricted  to  cases  where  there  is  a sin- 
gle cutting  edge,  such  as  turning.  The  problem  entails  quantifying  the  quality  of  the  cut 
and  relating  degradations  in  quality  to  a worn  tool.  The  difficulty  is  that  a large  number  of 
variables  are  involved  in  producing  tool  force.  Additionally,  in  multi-tooth  milling,  where 
there  is  more  that  one  cutting  edge  simultaneously  engaged,  it  is  difficult  to  isolate  the 
effect  of  a single  tooth. 

Unacceptably  large  vibrations  in  milling  may  produce  poor  surface  quality  and  lead 
to  premature  failure  of  the  tool  and  spindle.  A cause  of  large  vibrations  has  been  attributed 
to  a phenomenon  defined  as  regeneration  of  waviness,  which  can  result  in  self-excited 
vibrations  known  as  chatter  [25].  Methods  of  detection  and  avoidance  of  chatter  based  on 
sound  measurements  have  been  investigated  and  implemented  [13]. 

A review  of  tool  breakage  is  provided  in  the  articles  by  Tlusty  and  Tamg  [15],  and 
Richter  and  Spiewak  [26].  Tool  breakage  detection  has  gained  more  importance  in  recent 
years  with  the  progression  of  FMS.  Since  machining  with  a broken  tool  increases  tool 
force  variations  that  lead  to  large  vibrations,  condition  of  the  cut  will  be  degraded.  Also, 
the  excessive  vibrations  can  lead  to  the  premature  failure  of  the  machine  tool.  Even  with 
operator  supervision,  such  a detector  could  be  used  to  stop  the  machine  tool  rapidly.  By 
rapidly  stopping,  damage  to  the  workpiece  can  be  minimized. 

Research  can  be  divided  into  two  groups,  one  using  acoustic  emission  and  the  other 
using  an  analysis  of  the  periodicity  of  the  milling  force.  In  acoustic  emission,  a 
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piezoelectric  transducer  is  used  to  obtain  the  very  high  frequency  vibrations  of  the 
machine.  These  high  frequency  signals  are  produced  by  microfractures  of  the  workpiece 
and  tool.  Various  techniques  have  been  applied  to  detect  tool  breakage  from  this  signal, 
but  they  are  not  robust  due  to  the  sensitivity  to  cutting  parameters. 

Detection  methods  based  on  the  cutting  force  focus  on  the  periodic  nature  of  the 
force  signal.  Face  milling  with  tools  that  have  evenly  spaced  teeth  produces  a signal  that 
has  energy  focused  at  the  tooth  passing  frequency  and  its  harmonics.  Imbalances  in  the 
spindle  and  tool  as  well  as  the  nonuniform  radial  and  axial  length  of  the  teeth  will  produce 
a signal  periodic  with  each  spindle  revolution. 

Tool  breakage  produces  a rapid  change  in  signal  dynamics.  Both  spectral  analysis 
and  time  domain  approaches  have  been  used  to  extract  breakage  features.  Spectral  analy- 
sis methods  search  for  spectral  features  that  are  not  produced  by  normal  milling.  However, 
detection  needs  to  be  rapid,  which  means  that  the  short  data  record  must  be  used  to  pro- 
duce the  spectral  estimate.  Techniques  such  as  AR  and  ARMA  modeling  [27]  could  be 
used  to  increase  spectral  resolution  for  small  data  windows.  However,  due  to  the  short 
time  of  the  data  record,  the  presence  of  transients  introduced  by  changes  in  cutting  param- 
eters, and  noise,  these  approaches  have  not  produced  robust  solutions. 

Time  domain  approaches  use  prediction  to  detect  changes  due  to  tool  breakage.  One 
approach  uses  the  force  of  the  previous  tooth  to  predict  the  force  of  the  current  tooth  [28]. 
If  the  tooth  is  not  broken,  then  its  force  should  be  approximately  equal  to  the  force  of  the 
current  tooth.  Difficulties  arise  from  setting  the  threshold  to  compare  the  two  values,  espe- 
cially in  the  presence  of  tool  throw.  Another  approach  is  to  compare  the  force  of  the  cur- 
rent tooth  with  the  force  of  that  tooth  measured  during  the  previous  revolution  [29,  30,  31, 
32],  This  method  reduces  the  problem  associated  with  tool  throw  and  runout.  A final 
method  is  to  use  AR  models  to  predict  the  tooth  force  [33],  The  AR  model  is  adapted  to  fit 
the  data  during  normal  milling.  This  model  is  then  used  to  predict  the  tooth  force  for 
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comparison  with  the  actual  force.  A common  problem  with  all  approaches  lies  in  comput- 
ing a threshold  for  comparing  the  predicted  tooth  force  with  the  measured  tooth  force. 

In  chapter  2 the  model  for  multi-tooth  force  is  defined.  Chapter  3 presents  a time 
domain  approach  using  prediction  based  on  the  force  of  the  tooth  one  revolution  back.  The 
analysis  of  chapter  2 provides  the  framework  on  which  the  breakage  detector  is  defined. 

Distributed  Computer  Systems  Review 

There  are  several  good  books  that  provide  a review  of  distributed  computer  systems 
theory  [34,35,36],  Briefly,  a distributed  system  encompasses  a set  of  separate  computers 
that  are  capable  of  autonomous  operation  and  linked  by  a computer  network.  Such  sys- 
tems are  commonly  referred  to  as  loosely  coupled  computer  systems.  The  computers  can 
vary  in  power  from  simple  personal  computers  to  powerful  super  computers.  A communi- 
cation network  supplies  the  connection  by  which  the  various  machines  may  share  informa- 
tion and  resources. 

The  motivation  for  using  a distributed  system  can  be  derived  from  both  technical 
needs  and  economic  pressures.  With  the  advent  of  VLSI  and  mass  production,  the  smaller 
machines  have  fallen  dramatically  in  price.  High  speed  computer  network  technologies  are 
now  widely  available  at  low  cost.  The  concept  of  a distributed  system  allows  these  tech- 
nologies to  come  together  to  build  a powerful  computing  facility  at  a lower  cost  than  a sin- 
gle, high-power  computer. 

These  developments  have  rendered  Grosch’s  Law  largely  irrelevant  as  a basis  for 
planning  computer  systems  that  are  to  be  used  for  interactive  computing.  Grosch’s  Law 
states  that  the  processing  capacity  of  a computer  system  is  roughly  proportional  to  the 
square  of  its  cost.  It  was  originally  formulated  on  the  basis  of  Grosch’s  observation  of  the 
computer  marketplace  in  the  1960s  and  is  often  cited  as  a pragmatic  rule-of-thumb  provid- 
ing some  guidance  for  estimating  the  economies  of  scale  for  computing  systems. 

The  separation  of  components  is  an  inherent  property  of  distributed  systems.  Sepa- 
ration allows  the  truly  parallel  execution  of  programs,  the  containment  of  component 


12 


faults,  recovery  from  faults  without  disruption  of  the  whole  system,  and  the  incremental 
growth  or  contraction  of  the  system  through  the  addition  or  subtraction  of  components. 

Transparency  is  defined  as  the  concealment  of  separation  from  the  user  and  the 
application  programmer,  so  that  the  system  is  perceived  as  a whole  rather  than  a collection 
of  independent  components.  Although  many  types  of  transparency  have  been  defined,  for 
this  system  there  are  two  principal  types:  location  and  scaling. 

Location  transparency  enables  objects  to  be  accessed  without  knowledge  of  their 
location.  For  this  project,  the  collection  of  computers  will  contain  one  designated  as  a 
master,  one  known  as  the  CNC,  and  a variable  number  of  application  computers.  The  mas- 
ter will  work  as  a central  database  maintaining  the  identities  of  the  application  and  the 
identity  of  the  CNC.  When  an  application  machine  comes  on-line,  it  will  query  the  name 
of  the  master  by  broadcasting  a message  of  the  network.  Once  the  master’s  identity  is 
obtained,  the  application  will  register  itself  into  the  distributed  system.  With  the  identities 
of  the  various  machines  known  at  boot  time,  application  programmers  need  not  know  this 
information  to  communicate  with  the  master  or  the  CNC. 

The  other  transparency  type  of  concern  is  scaling  transparency.  Scaling  transparency 
allows  the  system  to  expand  in  scale  without  change  to  the  system  structure  or  the  applica- 
tion algorithms.  Network  access  will  be  handled  in  layers  (described  in  chapter  5),  which 
are  designed  to  hide  the  details  of  network  access  from  the  application  programmer  and 
the  user. 

Another  advantage  of  a distributed  system  is  predictable  response.  The  applications 
can  be  very  diverse,  with  each  having  its  own  computer  to  handle  the  serious  “number 
crunching.  The  size  and  power  of  the  computers  can  vary  to  fit  the  needs  of  a particular 
application.  The  ability  to  share  resources  is  a particularly  strong  point.  As  new  applica- 
tions are  developed,  the  application  can  be  inserted  into  the  network  and  have  equal  access 
to  the  CNC.  When  one  component  of  the  distributed  system  fails,  with  the  exception  of  the 
master  and  the  CNC,  most  of  the  work  of  the  system  need  not  be  interrupted. 
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Modeling  Based  on  Objects  and  Threads 

In  designing  a computer-based  system,  it  is  often  convenient  to  first  describe  the 
basic  functional  units.  A common  means  of  achieving  this  is  to  use  the  notion  of  software 
objects  [37],  An  object  comprises  a set  of  defined  states,  a current  state,  and  a set  of  oper- 
ations. This  notion  provides  a structure  by  which  the  basic  units  of  a computer-based  sys- 
tem can  be  encapsulated.  This  encapsulation  provides  for  isolation  of  system  functions. 

The  definition  of  a software  object  contains  no  temporal  notions.  Therefore,  threads 
of  control  are  defined  to  introduce  a partial  ordering  of  events  in  the  distributed  system.  A 
thread  of  control  is  a totally  ordered  set  of  events  defined  by  a programmer.  A distributed 
system  will  consist  of  multiple  threads  of  control  that  operate  in  parallel.  Such  concurrent 
threads  in  machine  monitoring  include  CNC,  sensor  acquisition,  state  estimation,  process 
update,  and  operator  monitoring. 

What  is  desired  for  distributed  systems  is  to  provide  each  machine  with  a service 
base  to  handle  distributed  operations  [38,39].  This  base  should  provide  an  interface  that 
only  requires  the  user  to  provide  specific  information.  For  example,  if  the  user  wants  to 
increase  the  spindle  speed,  then  a command  indicating  spindle  speed  change  and  the  new 
speed  is  all  that  should  be  required.  The  user  should  not  be  required  to  package  a message 
appropriate  for  the  ethemet,  determine  the  receiving  party’s  address,  verify  delivery,  or 
verify  that  the  CNC  accepted  the  change. 

In  a distributed  environment,  resources  may  have  complicated  structures.  For  exam- 
ple, where  are  the  data?  Where  are  the  programs  executed?  Who  possesses  these  data  and 
programs?  What  media  types  are  the  data?  When  abstracting  a resource  as  a software 
object,  this  information  is  included  as  private  information  of  the  object.  From  the  user 
level,  this  information  is  unnecessary  and  remains  invisible. 

Model  for  Systems  Integration 

Over  a period  of  time,  large  organizations  tend  to  collect  numerous  hardware  and 
software  systems  that,  for  the  most  part,  were  designed  to  run  in  isolation  or  in 
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cooperation  with  a small  subset  of  other  systems.  It  eventually  becomes  apparent  that 
great  improvements  in  productivity  can  be  gained  if  these  systems  can  be  allowed  to  com- 
municate directly  with  each  other  to  exchange  information.  Rusinkiewicz  et  al.  [40]  pro- 
poses the  use  a Local  Access  Manager  (LAM)  to  protect  the  autonomy  of  member 
software  systems.  The  LAM  or  service  base  provides  a high  level,  uniform  access  to 
remote  machines  that  will  be  used  to  build  network  applications. 

He  and  Tanaka  [41]  propose  abstracting  the  service  base  into  an  object-oriented  dis- 
tributed system.  Distributed  resources  are  abstracted  as  objects  containing  the  information 
of  the  resources.  A service  base  in  each  node  is  constructed  to  manage  these  objects. 

Underlying  Technology  for  the  Distributed  System 

The  underlying  technology  is  derived  from  two  sets  of  standards.  The  physical  spec- 
ifications and  means  of  connection  for  the  local  area  network  (LAN)  are  specified  by  the 
IEEE  Standards  Organization  [42,43].  This  specifies  the  physical  cable  characteristics,  the 
protocol  for  accessing  and  reading,  and  the  format  and  size  of  the  data  packets.  The  tech- 
nology specifies  a multiple  access,  bus-based  connection.  It  is  similar  in  access  to  the  bus 
of  the  computer  back  plane.  A hardware  independent  network  protocol  is  specified  by  the 
Internet  standard.  The  Internet  standard  is  an  ongoing  project  by  the  Internet  research  and 
development  community.  This  community  includes  ARPA  and  corporations  such  as  Sun 
Microsystems  and  Xerox.  They  follow  the  standard  set  down  by  the  International  Stan- 
dards Organization  for  open  systems  interconnection,  referred  to  as  the  ISO  OSI.  The 
Internet  standard  contains  a series  of  documents  specifying  the  various  pieces,  known  as 
the  request  for  comments  (RFC)  documents.  These  are  available  from  a public  file  server 
(nic.ddn.mil),  which  were  obtained  and  used  to  specify  the  networking  for  this  project. 

The  principle  goal  of  following  the  Internet  guidelines  was  to  maintain  compatibility  with 
the  existing  standard  for  wide  area  network  (WAN)  interconnection,  to  use  its  specifica- 
tion of  software  layers  to  aid  in  providing  transparency  to  application  programmers,  and  to 
use  existing  products  to  aid  in  constructing  the  machine  interconnection.  The  RFCs  that 
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were  used  will  be  referred  to  during  the  detailed  specification  of  the  network  hardware  and 
software  in  chapter  5. 

The  Internet  protocol  provides  a messaging  system  that  hides  many  of  the  details  of 
the  actual  communication.  The  required  information  is  the  name  (not  the  address)  of  the 
receiving  computer,  the  ID  of  the  receiving  routine,  the  length  of  the  data,  and  the  data. 
The  eXtemal  Data  Representation  (XDR)  developed  by  Sun  Microsystems  [44,45] 
describes  a means  of  data  abstraction.  This  is  a standard  used  for  interprocess  communica- 
tion that  uses  a data  type  identifier  and  a known  external  format  for  the  data. 

Development  Environment 

In  terms  of  research  goals,  the  system  is  being  developed  to  facilitate  an  environ- 
ment where  research  of  machine  tool  monitoring  can  be  performed  without  wasting  con- 
siderable time  on  interface  details.  Object-oriented  encapsulation  describes  the  interface 
of  the  system.  The  distributed  system  provides  the  means  of  increasing  the  number  of  con- 
current threads.  The  envisioned  system  will  provide  an  environment  where  a developer 
need  only  obtain  a computer  with  an  Ethernet  adapter,  use  a set  of  high  level  tools  pro- 
vided by  this  work,  and  concentrate  solely  on  their  tool  monitoring  algorithms.  The  high 
level  tools  will  provide  for  the  access  and  modification  of  the  CNC,  as  well  as  display  of 
results. 


Off-Line  Analysis  Tool 

As  a means  to  validate  the  tool  breakage  detector,  an  off-line  analysis  tool  was 
developed  to  aid  in  understanding  the  dynamics  of  the  data  and  to  validate  signal  process- 
ing algorithms.  The  importance  of  the  off-line  system  extends  past  its  significance  in  vali- 
dating algorithms  for  the  on-line  system.  It  also  plays  an  important  role  in  conjunction 
with  the  on-line  system. 

The  off-line  tool  was  designed  for  ease  of  use  by  providing  an  interactive  data  anal- 
ysis tool  in  the  algorithm  design  loop.  The  data  utilized  by  this  tool  is  identical  in  nature  to 
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that  seen  in  real-time  operations.  Algorithms  designed  under  this  tool  operate  in  a real- 
time fashion.  That  is,  they  process  data  one  sample  at  a time.  The  difference  is  that  a col- 
lection of  buffers  maintains  a record  of  intermediate  results  as  well  as  the  final  result.  On 
completion  of  data  processing,  these  data  are  available  for  inspection. 

The  supervision  system  has  the  function  of  in-process  monitoring.  In  this  capacity  it 
will  stop  the  machine  after  tool  failure.  However,  in  a research  environment  there  is 
another  important  function.  The  supervision  system  can  capture  data  and  pass  them  to  an 
off-line  system.  Here,  the  researcher  can  inspect  the  data  in  greater  detail.  Information 
gained  from  this  inspection  can  be  used  for  improvements  to  current  algorithms  or  as  a 
basis  for  future  algorithms. 


Summary 

Chapter  2 presents  an  extension  of  the  force  model  for  single  tooth  milling  to  the 
case  of  multi-tooth  milling.  This  chapter  addresses  the  observability  of  milling  parameters 
known  from  the  single  tooth  case  when  working  with  multi-tooth  data.  Simulations  of  the 
model  are  compared  to  real  data. 

Chapter  3 builds  on  chapter  2 to  describe  the  observability  of  both  the  tooth  break- 
age transient  and  the  missing  tooth.  Methods  of  feature  extraction  and  threshold  adjust- 
ments are  described  in  terms  of  the  force  model  presented  in  chapter  2. 

Chapter  4 presents  the  problem  of  machine  tool  supervision  in  terms  of  a loosely 
coupled  distributed  system.  The  concepts  of  encapsulation  from  object-oriented  analysis 
and  scheduling  based  on  control  threads  are  used  to  describe  fully  the  distributed  system. 
This  chapter  also  covers  the  detail  for  the  network  communication  software. 

Chapter  5 describes  the  method  by  which  an  AI  Flexmate  computer  numerical  con- 
toller  (CNC)  is  extended  in  order  to  make  it  available  as  a network  resource.  Chapter  6 
presents  the  on-line  supervision  system  from  the  perspective  of  the  operator.  Its  features 
are  described,  as  well  as  further  implementational  details. 
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Chapter  7 describes  an  off-line  data  analysis  tool.  This  tool  was  used  to  design  and 
test  the  signal  processing  algorithms  prior  to  on-line  implementation.  This  tool  provides 
an  intuitive  interface  for  doing  detailed  data  analysis.  It  is  used  alongside  of  the  on-line 
system  for  debugging  as  well  as  investigating  events  of  interest  during  milling. 

Chapter  8 concludes  the  work  by  presenting  overall  results  relating  to  significance 
and  success  of  the  project.  Future  directions  for  this  project  are  presented. 


CHAPTER  2 
FORCE  MODEL 

Current  Models  for  Milling  Force  Estimation 
Metal  cutting  can  be  described  as  a process  involving  friction,  plastic  flow,  and  frac- 
ture of  material  [12],  and  various  models  have  been  used  to  predict  its  forces.  Models  for 
orthogonal  cutting,  where  the  cutting  edge  is  perpendicular  to  the  direction  of  feed,  have 
received  extensive  research,  and  a literature  review  is  presented  here  to  outline  various 
principles  on  which  the  force  model  is  developed. 

Approaches  to  modelling  these  forces  have  recognized  the  complex  process 
involved  in  metal  cutting.  A critical  problem  with  most  approaches  is  the  dependence  on 
parameters  that  are  not  available  [12,46,47,48],  Fortunately,  a usable  model  for  milling 
forces  does  exist  [46,49].  It  states  that  the  force  tangential  to  the  tooth  trajectory  is  propor- 
tional to  the  area  of  the  undeformed  chip  thickness 


fT  = KsaC,  (EQ  2-1) 

where /j-  is  the  force  tangent  to  the  tooth  trajectory,  Ct  is  the  instantaneous  unde- 
formed chip  thickness,  a is  the  axial  depth,  and  Ks  is  the  specific  cutting  pressure.  The 
specific  cutting  pressure,  Ks,  is  dependent  on  the  undeformed  chip  thickness  by  [50] 

Ks  = (EQ  2-2) 

where  cc  and  [3  are  constants.  However,  the  use  of  an  average  value  of  Ks  is  accept- 
able and  provides  a more  usable  model  [46,49].  Undeformed  chip  thickness  in  face  mill- 
ing can  be  approximated  as 


C(  = S(sin<)> 


(EQ  2-3) 
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where  St  is  the  feed  per  tooth  and  <j)  is  the  tooth  angle  relative  to  feed  direction  (fig- 
ure 2-1).  This  model  is  valid  for  values  of  St  much  smaller  the  than  tool  radius.  The  para- 
sitic force  components  due  to  the  rake  and  flank  face  (rake  angle,  clearance  angle,  round 
rake  nose)  can  be  included  by  extending  equation  2-1  to  [51,52,53] 

fT  = KsaS,s in<))  + Ksah  (EQ  2-4) 

jjj 

where  * is  a constant  for  a particular  workpiece/tool  combination.  This  model  has 
two  components.  The  first  is  directly  proportional  to  the  undeformed  area  of  cut.  The  sec- 
ond is  directly  proportional  to  the  length  of  the  cutting  edge.  The  edge  components  are 
significant  at  low  chip  loads.  A force  normal  to  fT  can  be  modeled  as 

/r  = riKsaSlsinfy  + r2Ksah * (EQ  2-5) 

where  r}  and  r2  are  constants  for  a workpiece/tool  combination.  These  are  average 

values  that  model  the  effects  of  shearing  stress,  shearing  angle,  and  frictional  forces.  The 
values  rl  and  r2  represent  the  ratio  of  radial  to  tangential  forces  on  the  rake  and  flank  face. 
These  values  are  not  in  actuality  constant,  but  this  model  has  proven  reasonably  accurate 
[52,54]. 

The  single  tooth  force  model  has  been  extended  to  include  effects  of  nonrigid  work- 
piece  and  machine  tool  [53],  but  the  model  presented  here  will  be  used  to  discuss  the 
dynamics  involved  in  rigid  milling. 
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Single  Tooth  Force  in  Up  Milling 

The  cutting  force  vector  is  measured  in  two  dimensions  (figure  2-1).  This  plane  lies 
parallel  to  the  face  of  the  tool.  The  force  vector  is  a complex  quantity  having  magnitude 
and  phase,  where  the  phase  of  the  tangential  force  is  dependent  on  the  spindle  speed,  the 
radial  length  of  the  teeth,  and  the  direction  and  speed  of  the  workpiece  relative  to  the  tool. 
However,  assuming  the  velocity  of  the  tooth  due  to  spindle  speed  is  much  larger  than  the 
feed  rate,  a phase  model  based  on  spindle  speed  and  tooth  radius  is  reasonable.  This  model 
has  been  used  for  rigid  workpiece  and  machine  tool  systems.  The  radial  force  will,  of 
course,  always  be  normal  to  the  tangential  force  (figure  2-1). 

With  these  assumptions  and  approximations,  the  single  tooth  force  is  represented  as 
the  complex  quantity 


, ;(4>  + -) 

= Ksa(S,sin<$>  + h )e  1 = Ksa  (Shinty  + h* )je)l*  (EQ  2-6) 

/*(<!>)  = Ksa  (rlSlsm<9  + (HQ  2-7) 

which  gives  the  total  single  tooth  force  as 

t>)  = *>  1 ( 'i  +J)  S,  sin  6 + ( r,  +j)  h * ] <r/*  (EQ  2-8) 

To  account  for  radial  immersion,  we  propose  to  define  a masking  operator  as  a func- 
tion of  entry  and  exit  angle: 


">(<!>)  = { 


l 

0 


0<  ♦*<$<•!>«<* 
elsewise 


(EQ  2-9) 


where  and  are  the  entry  and  exit  angles  of  the  tooth  measured  such  that  the 
direction  of  feed  is  at  90  degrees. 


Fourier  Spectrum  of  Single  Tooth  Force 

Since  fp(§)  is  periodic,  the  spectrum  will  consist  of  the  values  at  the  fundamental 
and  its  harmonics  [55].  That  is 


21 


/,(♦>  = s V"0 

n = — <*» 

where 


(EQ  2-10) 


Fn  = 2i  (EQ  2-11) 

— 7t 

The  concept  of  decomposing  the  force  signal  into  a Fourier  series  has  been  pre- 
sented in  Yellowley  [56],  However,  its  implications  to  the  multi-tooth  force  model  were 
not  addressed  and  will  be  presented  here. 

An  example  of  a power  spectrum  for  the  periodic  function  fp(<\>)  is  shown  in  figure  2- 
2.  This  figure  emphasizes  the  fact  that  periodic,  continuous  signals  are  represented  by  a 
discrete  spectrum  (equation  2-10).  The  values  for  the  Fourier  series  Fn  can  be  calculated 
from  equation  2-11.  From  equation  2-8  and  equation  2-11,  using  the  limits  of  equation  2- 
9,  we  can  calculate  the  spectral  values  of  the  single  tooth  force  signal  (equation  2-12). 


F_  = 


2 7C 


~$t  (rl  +j) 


S,(rl  +j ) j sin  (<)>)  e~Jin~  + (r2+j)h"  fe 

jh'  ( r2+j)' 
n - 

jh  ( r2+j )' 


Ksa  +J) 

F-  = to  { L^Oi-2)  {~jin  " 1}  ***•  " C0S<M  + 


n(n-  2) 


(~j(n  - 1)  sin <|>.  - cos<|>.)  + 


n-  1 


*.  \ 

->(»-  !)♦, 
} 


(EQ  2-12) 
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The  first  Fourier  coefficients  are  as  follows  (equation  2-13): 


Ksa 

Fo=^{S'('ri+j) 


r em-  ej2*>  A fib 

. 4 + 4 +J  2 1 2J 


+ h (r2+j)[-jeJ'‘+jeJ*>]} 


K,a 


F\  = 27  (-cos^  + cos^)  +h  (r2  + 2)  - <)>fc)  } 


Ksa 

F2  = ^{S,(rl+j) 


~j2*t  ~fl*b 


4 ; 2 +;"2  J 


+ * (r2+;)  [/'« ‘11 


(EQ  2-13) 


These  equations  are  interesting,  because  they  define  the  values  of  the  Fourier  com- 
ponents as  a function  of  entry  and  exit  angle.  However,  the  fact  that  the  signal  can  be 
decomposed  is  of  more  immediate  importance.  A discrete  time  version  will  be  introduced 
later  that  is  useful  for  computer  simulation  and  digital  signal  processing. 


Multi-Tooth  Model 

The  multi-tooth  force  signal  is  the  summation  of  the  single  tooth,  complex  valued 
force  signal  [49].  We  propose  to  model  the  interaction  of  the  different  teeth  to  produce  the 
composite  milling  force  as  a linear  system,  which  we  call  the  force  composition  filter. 
Each  tooth  produces  a force  fp(ty).  Due  to  the  harmonic  relation  among  these  signals  (the 
model  assumes  that  the  teeth  are  uniformly  distributed  in  the  cutter),  the  total  output  force 
can  be  computed  as 


nt-  i 

M)  = X/pOt*—*)  (EQ  2-14) 

k = 0 T 

where  NT  equals  the  number  of  teeth  on  the  tool. 

Notice  that  the  total  force  is  written  as  a function  of  the  force  on  a single  tooth. 
Therefore,  we  can  model  this  operation  as  a filter,  the  force  composition  filter,  which 
receives  as  the  input  the  single  force  and  produces  the  total  output  force  (figure  2-3).  The 
transfer  function  of  such  a system  can  be  now  easily  written  as 


F(S)  = L 


1 2k 

I /,<♦-«« 

■k  = 0 ‘ - 


= I* 


2k  i 


k = 0 u T 

The  closed  form  solution  can  be  written  as 


K 

— ks 


NT~  1 

= I Nt 

k = 0 


(EQ  2-15) 
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This  model  is  important  for  the  theory  of  machining  because  the  input  to  the  force 
composition  filter  is  the  waveform  that  carries  the  information  regarding  the  parameters  of 
the  milling  operation  (depth  of  cut,  radial  and  axial  depth  of  cut),  but  the  waveform  that 
we  measure  with  the  probes  connected  to  the  milling  machine  is  the  output  of  the  force 
composition  filter.  An  interesting  question  that  will  be  addressed  below  is  what  milling 
parameters  can  we  infer  from  the  observation  of  the  output  of  the  force  composition  filter. 
In  order  to  shine  light  on  this  question  we  start  by  analyzing  the  properties  of  the  transfer 
function  of  the  force  composition  filter. 

This  filter  has  zeros  at 

5 = 0,  ±j,  ±j2, . . . 

and  poles  at 

5 = 0,  ±jNv  ±j2Nv  ... 

All  of  the  poles  align  with  zeros  of  the  system  (e.g.,  a pole  zero  cancellation  occurs), 
which  produces  a multiple  band  pass  filter  called  a comb  filter.  The  magnitude  of  this  sys- 
tem for  Np=S  is  given  in  figure  2-4.  The  center  frequencies  for  the  system  are  at  0,  8, 16, ... 
cycles/rev.  The  frequency  at  8 cycles/rev.  for  an  8 tooth  tool  is  more  commonly  referred  to 
as  the  tooth  frequency. 

Implications  of  Fourier  Analysis  on  Multi-Tooth  Milling 

When  T/^Ctf))  is  processed  by  the  force  composition  filter,  the  power  spectrum  of  the 
periodic  signal  will  take  the  form  of  figure  2-5.  This  power  spectrum  is  obtained  by 
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Figure  2-4.  Spectrum  of  force  composition  filter  for  NT=8. 
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passing  the  original  signal  (figure  2-2)  through  the  force  composition  filter  (figure  2-4). 
We  can  immediately  predict  that  not  all  of  the  properties  of  the  signal/^)  can  be  esti- 
mated from  the  observation  of  the  output  force.  The  fore*?  composition  filter  cancels  spec- 
tral information  at  all  harmonics  except  DC  and  the  multiples  of  the  number  of  teeth  in  the 
cutter. 

Another  consequence  of  this  analysis  is  that  the  only  information  pertaining  to  mill- 
ing forces  left  after  composition  is  contained  in  the  spectrum  near  the  vicinity  of  multiples 
°f  NT-  A11  the  other  spectral  information  in  the  force  signal  can  be  attributed  to  noise,  tool 
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throw,  and  runout,  which  can  be  discarded.  Therefore  we  recommend  comb  filtering  of  the 
force  signal  at  multiples  of  the  tooth  frequency  to  improve  the  signal  to  noise  ratio.  Equa- 
tion 2-16  presents  such  a filter. 

The  effect  of  the  composition  of  the  forces  from  individual  teeth  is  similar  to  a sam- 
pling operation  in  the  spectrum  of  the  original  single  tooth  force.  As  is  well  known  from 
digital  signal  processing  theory,  sampling  in  one  domain  produces  periodic  repetitions  in 
the  other  domain.  So  when  we  sample  the  spectrum  with  a period  of  NT,  we  will 

periodically  repeat  the  waveform/^)  every  2nJNr  times.  That  is,JJ,(<|>)  has  a period  of  2k, 
while /(<}))  has  a period  of  2kJNt.  This  is  exactly  what  we  started  with,  Nj  teeth  forces 
along  one  revolution.  So  the  consistency  of  the  composition  force  filter  is  proved. 

The  implications  of  this  operation  must  be  now  studied  carefully,  because  as  is  well 
known,  sampling  may  carry  with  it  the  problem  of  aliasing,  i.e.,  the  original  signal  may 
not  be  recoverable  from  the  composite  signal.  We  can  immediately  conclude  from  this 
analysis  that  when  more  that  one  tooth  is  in  contact  with  the  workpiece,  aliasing  will  be 
present  in  the  composite  force  signal,  and  we  will  not  be  able  to  directly  recover  from/(<{)) 
the  milling  parameters  earned  in  fp(§).  This  is  ironic,  because  these  are  normally  the  oper- 
ating conditions  of  the  cut  for  efficiency.  The  aliasing  will  be  progressive  from  shallow  to 
deep  immersion  cuts,  but  one  can  expect  that  whatever  signal  processing  methods  are  used 
to  extract  cut  information  from  the  total  force,  their  accuracy  and  robustness  will  deterio- 
rate with  immersion. 

Figure  2-6  contains  plots  of  simulated  signal  fp(t j>),  an  overlay  containing  the  indi- 
vidual fp(§)  for  each  tooth,  and_/T<t>)  using  our  model.  The  simulation  was  performed  in 
MATLAB.  These  three  signals  are  then  shown  for  radial  immersions  of  12.8%,  50%,  and 
100%,  and  a tool  with  8 teeth.  The  left-most  column  is7p((j)).  The  center  column  shows 
/p(< 10  for  each  of  the  eight  teeth.  The  right  column  contains /(<}>).  The  signal has  a 
period  of  2k.  The  force  composition  filter  produces  a signal  fity)  that  has  a period  of  2rc/8. 
An  immersion  of  12.8%  was  chosen  so  that  only  one  tooth  is  in  contact  with  the 
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workpiece.  As  can  be  seen,fp(<$>)  can  be  directly  recovered  from^<|>).  As  immersion 
increases,  so  does  the  overlap  of  the  features,  which  partially  obscures  the  features  of 

fPW- 

Aliased  signals,  in  general,  cannot  be  recovered.  However,  recovery  may  be  possible 
given  a priori  knowledge  of  the  original  signal.  Since  the  signal^(<}))  is  rather  simple, 
there  is  still  some  hope  of  estimating  some  of  the  parameters  of  the  cut  from  the  aliased 
composite  signal.  But  this  is  a nontrivial  signal  processing  problem  and  will  not  be 
addressed  here.  The  following  sections  are  devoted  to  the  task  of  using  the  spectral  fea- 
tures at  the  multiples  of  the  tooth  frequency  to  extract  milling  parameters. 

Discrete  Time  Force  Model 

The  analysis  in  the  previous  sections  is  presented  as  a continuous  time  system.  Since 
this  is  the  domain  of  the  machining  process,  this  analysis  is  appropriate.  In  the  experimen- 
tal setup  data  are  synchronously  sampled.  That  is,  a fixed  number  of  samples  are  taken 
during  each  revolution.  Synchronous  sampling  allows  a straight  formulation  of  the  above 
model  to  the  digital  domain,  otherwise  a much  more  involved  framework  would  be 
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necessary.  The  problem  is  that  in  fact  <j)  is  a function  of  time,  but  when  one  samples  syn- 
chronously, this  dependence  can  be  omitted.  The  sampled  version  of  the  single  tooth  force 
signal  (equation  2-8)  is 


2it 

~ r~  2K  ~]  J — n 

fp(n)  = K1a^J.rl+j)S,^n(.—n)  + (r2+j)h’je  N (EQ2-17) 

where  N equals  the  number  of  samples  per  revolution.  The  spectral  values  are  esti- 
mated through  the  discrete  fourier  transform  (DFT),  so  equation  2-12  becomes 


fP(k)  = £ fs(n)e  N ,0£nb<ne<^ 


g(k)  = 


-j<aknb  —j&kn 

e — e 


1 - e 


-j(ok 


,k>  o 
,k= o 


^,(ri+7) 

fp(k)  = Ksa  { — (g(k  - 2)  - g(k))  +h  (r2  +j)  g(k  - 1)} 

where  ~ denotes  a periodic  sequence. 


(EQ  2-18) 


Extracting  Milling  Constants 

Equation  2-17  relates  the  single  tooth  force  with  four  parameters  (Ks,  rj,r2,  and  h*), 
which  are  constant  for  a particular  workpiece/tool  combination  and  which  will  be  called 
the  milling  constants.  The  milling  constants  can  be  estimated  using  the  methods  of  least 
squares.  The  multi-tooth  force  signal  f(n)  can  be  recorded  from  the  milling  machine  under 
different  cutting  conditions.  A measurement  vector  is  produced  by  estimating  spectral  val- 
ues from  the  data  and  solving  for  the  unknowns  under  the  constraints  of  equation  2-18. 
The  method  of  the  least  squares  can  solve  the  overdetermined  system 

Ax  = b (EQ  2-19) 

where  b will  be  the  measurement  vector,  A the  parameter  vector  (equation  2-18)  and 

x the  milling  constants.  Experimentally  we  found  that  the  complex  valued  force  compo- 
nent at  DC  and  the  magnitude  of  the  tooth  fundamental  are  sufficient  to  produce  a reason- 
able estimate  of  the  milling  constants.  This  means  that  the  matrix  A has  only  2 columns. 
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For  this  experiment,  the  force  was  estimated  by  measuring  the  spindle  displacement 
[1 1].  A series  of  cuts  with  varying  angle  of  radial  immersion  were  chosen  so  that  there 
would  be  examples  for  different  levels  of  overlap  for  the  single  tooth  force  signals ,fp(n). 

At  the  frequencies  observable  through  the  force  composition  filter,  the  spectrum  of 
fp{ri)  will  correspond  to  a scaled  version  of  the  spectrum  oij{n)  by  the  following  relation. 

F(k) 

FpW  = Iv-’*  = O’tNp  ±2Nr  - (EQ  2-20) 

/ 

This  feature  is  exemplified  through  the  spectral  plot  of  figure  2-4.  The  complex 
spectral  values  fovfp(0)  are  easily  obtained  from  the  milling  data  and  are  used  to  estimate 
the  milling  constants.  The  magnitude  of  the  complex  spectral  values  for  fp(NT)  is  also  used 
since  the  tool  used  in  the  experiments  is  known  not  to  have  any  major  modes  in  this  region 
of  the  spectrum.  Specifically,  at  full  immersion  the  tooth  fundamental  is  produced  by  edge 
effects  alone,  as  shown  in  equation  2-21.  To  emphasize  this  feature,  test  cuts  include  full 
and  deep  immersion.  Additionally,  this  feature  is  small  in  comparison  to  features  at  DC.  In 
terms  of  standard  least  squares,  small  valued  features  will  discounted.  For  this  reason  a 
weighted  least  squares  is  used  to  give  each  measurement  equal  influence  on  the  solution. 

fp(nt ) = Ksh*  (r2  +j)  [ag(k  - 1)]  (EQ  2-21) 

Equation  2-18  can  be  rearranged  into  a system  with  two  unknowns,  where  the 

unknowns  (grouped  by  brackets)  are  the  milling  constants. 

aS, 

Fp(k)  = (jz  (g(k- 2)- g(k)))  [Ks(ri+j)]  + (ag(k-  1))  [Ksh*  (r2  +_/)]  (EQ  2-22) 

Since  the  complex  spectral  values  cannot  be  estimated  at  f(Nj)  (only  the  magnitude 
is  available),  a straightforward  least  squares  solution  is  not  possible.  Moreover,  due  to  the 
dynamic  range  of  measured  spectral  features,  a normalization  is  desirable  to  give  equal 
weight  to  all  the  measurements.  The  problem  is  set  up  as  a weighted  least  squares 

WAx  = Wb 

where  the  least  squares  error  is  defined  as 


(EQ  2-23) 
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E = ||  WAx-Wb\\  (EQ  2-24) 

The  solution  is  set  up  to  minimize  an  error  vector.  The  matrix  A has  two  columns 

with  elements 


aS, 

“ O'. 1 ) = (g(k  - 2)  - g(k))  (EQ  2-25) 

a(<»  2)  = ag(k  - 1)  (EQ  2-26) 

Each  row  of  A corresponds  to  a particular  spectral  value  of  Fp(k).  The  vector  a:  is  set 


up  as 


X 


r\  +j 
(r2+j)_ 


The  vector  b is  then  set  at 


(EQ  2-27) 


b = [/„(°)  /,,«>)  /,3(0)  - [4,(^r)j  \fp(NT)\  \fpWT)\  ,.]r  (EQ  2-28) 

where  the  rows  of  A and  b correspond  to  the  same  spectral  feature  and  the  lower  sub- 
script on  the  elements  of  b denote  the  data  record.  Since  b contains  complex  spectral  val- 
ues as  well  as  magnitudes,  we  found  that  taking  the  magnitude  of  some  of  the  elements  of 
the  vector  Ax  before  E is  computed  increases  the  reliability  of  the  solution.  The  weighting 
matrix  is  constructed  as 


w=  diag(lfll)-1 

0 


(EQ  2-29) 


The  error  vector  E is  then  minimized  by  gradient  descent.  The  significance  of  nor- 
malizing E is  to  ensure  that  each  element  of  B will  have  equal  weight  in  determining  the 
error. 


Experimental  Results 

Force  estimates  from  five  cuts  were  used  to  estimate  the  milling  constants.  These 
cuts  were  taken  for  up  milling  using  a 4”  tool  with  8 teeth.  All  cuts  were  performed  at  600 
RPM  with  a feed  per  tooth  of  0.00583  inches  per  tooth.  The  radial  depth  (r^)  and  axial 
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depth  (ad)  are  listed  in  table  2-1.  All  cuts  have  a radial  entry  point  ( n at  zero.  The  radial 
exit  point  (ne)  and  immersion  percentage  are  listed  in  table  2-1,  as  well  as  the  spectral  fea- 
tures that  were  extracted  and  used  to  estimate  the  milling  constants. 


TABLE  2-1.  Experimental  data. 


case 

# 

rd 

ad 

ne 

immersion  f(0) 

lf(8)l 

1 

0.3” 

0.050” 

10 

7.5% 

17.1+J122 

77.3 

2 

1.0” 

0.050” 

20 

25% 

-44.5+j341 

53.1 

3 

2.0” 

0.050” 

30 

50% 

-174+J580 

94.8 

4 

3.7” 

0.040” 

50 

92.5% 

-477+j666 

76.8 

5 

4.0” 

0.040” 

60 

100% 

-610+j548 

7.88 

Several  solutions  were  found  (for  different  initial  conditions)  that  gave  very  similar 
errors.  Plugging  these  values  into  equation  2-17  showed  that  these  solution  did,  in  fact, 
produce  very  similar  force  signals.  Consider  the  following  two  solutions: 


TABLE  2-2.  Simulation  results. 


case  1 

case  2 

Ks 

1.32xl06 

1.3xl06 

rl 

0.784 

0.808 

r2 

1.13 

0.786 

h* 

2.69x1  O'4 

3. 26x1  O'4 

error 

1.03 

1 

The  value  of  Ks  and  r j were  relatively  constant  among  all  solutions.  However,  the 
values  of  ^2  and  h suffered  more  variance,  possibly  due  to  sensitivity  to  edge  effects.  Nev- 
ertheless, the  method  produced  values  that  correspond  to  the  real  data.  Plots  of  the  results 
for  case  1 and  2 are  presented  in  figure  2-7.  Both  the  real  and  imaginary  portions  of fp(n) 
are  shown  for  each  case,  with  the  two  cases  overlaid.  Case  1 is  drawn  with  a solid  line,  and 
case  2 is  drawn  with  a dashed  line.  The  plots  represent  fp(n)  at  full  immersion  for  half  a 
revolution.  Figure  2-8  shows  an  overlay  for  the  simulated  force  composition  filter  output 
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from  case  1 and  the  actual  data  from  record  1 (table  2-1).  The  simulated  signal  (designated 
by  a solid  line)  was  produced  by  applying  a mask  to  fp(n)  for  the  immersion  angles  of  data 
record  1 (n^= 0,  ne=  10).  The  final  signal  was  produced  according  to  force  composition  fil- 
ter (equation  2-14).  The  data  from  the  recorded  milling  test  (designated  by  a dashed  line) 
was  comb  filtered  (equation  2-16)  to  remove  effects  of  runout  and  tool  throw.  Differences 
between  the  simulation  and  the  actual  data  can  be  attributed  to  the  fact  that  the  spindle  is 
not  completely  rigid  which  affects  the  method  of  predicting  tooth  force  from  the  spindle 
vibrations.  Figure  2-9  shows  an  overlay  for  data  record  2. 
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Conclusions 

Several  important  implications  to  the  theory  of  machine  tools  are  derived  from  the 
proposed  force  composition  filter.  The  force  produced  by  each  individual  tooth  in  cutters 
with  equally  spaced  teeth  is  only  partially  measured  by  sensors  installed  in  a machine  tool. 
Some  of  the  properties  of  the  cutting  force  will  be  obscured  (such  as  radial  depth).  This  is 
due  to  the  fact  that  the  linear  operation  of  the  composition  filter  partially  destroys  the 
information  contained  in  the  force  produced  per  tooth.  We  modelled  this  as  a sampling 
operation  on  the  spectrum  of  the  force  per  tooth.  The  overlap  of  single  tooth  force  signals 
(in  signal  processing  terms  this  destruction  is  aliasing)  is  progressively  more  severe  for 
deep  immersion,  the  condition  more  commonly  found  in  practice.  We  got  interested  in 
estimating  the  force  per  tooth  because  we  would  like  to  estimate  the  radial  depth  and  help 

set  thresholds  for  automated  cutting  breakage.  This  work  will  be  addressed  in  a follow  up 
paper. 

The  effect  of  synchronous  sampling  limits  the  observable  spectrum  to  y, 

where  the  subscript  denotes  the  number  of  cycles  per  revolution  and  TV  denotes  the  number 
of  samples  per  revolution.  So  N dictates  the  highest  harmonic  that  can  be  measured  with- 
out aliasing  in  the  digitization  procedure.  Increasing  N will  increase  the  number  of  observ- 
able features.  The  distribution  of  spectral  energy  of  fp(ty)  varies  widely  with  cutting 
conditions.  By  specifying  the  geometry  of  the  cut,  the  desired  number  of  samples  per 
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revolution  can  be  chosen.  Since  it  is  difficult  to  install  an  anti-aliasing  filter  prior  to  syn- 
chronous sampling,  the  expected  bandwidth  of  the  input  signal  needs  to  be  considered, 
before  choosing  the  sampling  rate. 

Another  implication  of  our  theoretical  work  is  the  design  of  appropriate  filters  to 
clean  the  noise  in  the  collected  force  or  displacement  signals.  Our  analysis  shows  that  the 
information  concerning  the  force  signal  is  concentrated  at  the  harmonics  of  the  tooth  fre- 
quency, so  a comb  filter  should  be  utilized. 

When  machining  with  evenly  spaced  teeth,  the  number  of  teeth  (NT)  determines 
which  of  the  spectral  values  will  be  observable.  That  is,  given  A^the  observable  spectral 
values  will  be  at/0,  fNt,  ...,/jyyf  where  k is  an  integer  and  kNt  is  less  than  N.  However, 
certain  implementations  of  digital  filters  require  that  iVis  an  integer  multiple  of  NT.  Such  a 
digital  filter  is  the  discrete  version  of  equation  2-16. 

i-z~N 

H(z)  = — (EQ  2-30) 

l-zNr 

Requiring  the  quantity  (N/NT)  to  be  an  integer  simplifies  the  design  of  comb  digital 
filters.  This  arrangement  allows  filters  to  take  direct  advantage  of  the  force  models. 

As  observed  by  equation  2-8,  the  specific  cutting  pressure  ( Ks ) and  the  axial  depth 
(a)  will  set  a constant  gain  across  all  features.  Since  these  two  parameters  are  not  separa- 
ble, a priori  knowledge  of  Ks  and  the  assumption  that  it  is  constant  are  key  to  estimating 
the  value  of  a. 

There  are  two  key  elements  of  equation  2-18,  nb  and  ne.  Knowledge  of  these  param- 
eters define  the  overlap  of fp(§)  for  producing^).  This  feature  is  fundamental  in  predict- 
ing the  effect  of  broken  teeth.  Knowledge  of  these  two  parameters  would  make  it  possible 
to  decompose  f(§)  into^,((j)),  even  after  the  aliasing  using  the  definition  of  fp(§)  (equation 
2-17). 

The  equations  derived  here  can  also  be  applied  to  extract  the  milling  constants  for  a 
given  milling  job.  We  utilized  a weighted  least  squares  approach  to  identify  the  relevant 
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parameters  of  milling.  In  the  literature,  the  method  of  obtaining  milling  constants  is  some- 
time obscure.  Although  our  method  has  to  be  handled  carefully  to  obtain  reasonable  solu- 
tions, it  provides  a stable  paradigm  to  identify  the  milling  constants.  The  two  effects  that 
need  attention  are:  the  proper  normalization  of  the  estimated  values  due  to  the  large 
dynamic  range  (1:20)  of  the  measured  forces  at  different  harmonics  (otherwise  the  identi- 
fication will  not  give  proper  weight  to  all  measurements).  The  second  aspect  is  the  fact 
that  some  of  the  parameters  of  the  model  are  complex  quantities  but  the  unknown  vari- 
ables have  real  values.  The  way  we  controlled  this  problem  was  to  perform  gradient 
descent  to  solve  for  the  optimal  solution  and  take  absolute  values  of  the  complex  quanti- 
ties to  guarantee  a real  solution. 


CHAPTER  3 

TOOL  BREAKAGE  DETECTOR 
Problem  Statement  and  Goals 

Since  machining  with  a broken  tool  increases  the  intensity  of  the  vibratory  tool 
force,  quality  of  the  cut  will  be  degraded.  Also,  the  excessive  vibrations  can  lead  to  prema- 
ture failure  of  the  machine  tool.  Therefore,  automated  methods  to  rapidly  stop  the  milling 
machine  are  desirable.  Even  with  operator  supervision,  such  a detector  could  be  used  to 
stop  the  machine  tool  rapidly  so  that  damage  to  the  workpiece  would  be  minimized. 

The  focus  of  the  detector  is  in  finding  the  transient  produced  when  a tooth  breaks. 
The  idea  of  transient  is  intrinsically  associated  with  the  background  signal  in  the  sense  that 
a transient  is  a modification  of  the  background  signal  due  to  changing  conditions.  The 
contrast  to  this  is  the  observation  of  a broken  tooth  without  observing  the  transient  associ- 
ated with  tooth  breakage.  This  problem  can  be  considered  as  the  observation  of  a missing 
tooth,  or  as  the  observation  of  excessive  tool  throw.  A method  of  observing  the  transient 
will  be  presented  first,  followed  by  a method  of  observing  a missing  tooth. 

Obtaining  the  Force  Estimate 

Tlusty  and  Andrews  [11]  presented  a critical  review  of  sensors  for  estimation  of  tool 
force,  and  concluded  that  displacement  signal  provides  the  necessary  bandwidth  in  addi- 
tion to  being  a realizable  sensor.  The  use  of  this  signal  and  its  characteristics  were  pre- 
sented in  chapter  2,  where  a model  was  introduced  that  defined  the  relationship  between 
the  single  tooth-force  and  the  observable  multi-tooth  force.  This  model  provides  the  theo- 
retical means  for  constructing  the  tool  breakage  algorithm. 

The  Machine  Tool  Research  Laboratory  at  the  University  of  Florida  equipped  a 
Series  20  Omnimil  machine  tool  with  inductive  sensors  embedded  in  the  spindle  housing. 
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Figure  3-1  depicts  a frontal  view  of  the  setup.  The  probes  consist  of  small  coils,  which 
have  an  inductive  value  that  varies  depending  on  the  distance  between  the  probe  and  the 
spindle.  Two  probes  are  used  for  each  axis  to  compensate  for  thermal  drift. 

Sampling  is  taken  synchronously.  This  is  accomplished  by  attaching  an  encoder 
wheel  to  the  rear  of  the  spindle.  The  encoder  wheel  generates  120  pulses  per  revolution, 
triggering  data  acquisition.  Synchronous  sampling  is  key  to  the  development  of  the  model 
for  tool  breakage. 

Displacement  Signal  Features 

Before  presenting  the  theoretical  background  of  the  tool  breakage  detector,  a practi- 
cal introduction  to  the  characteristics  of  the  displacement  signal  is  provided.  The  displace- 
ment signal  is  a function  of  many  variables.  In  chapter  2 the  nature  of  this  signal  was 
analyzed  to  see  what  basic  features  are  observable  from  the  measured  force.  In  that  discus- 
sion parameters  were  held  constant.  This  mode  of  operation  is  referred  to  as  “steady  state 
milling’’. 

Idle  milling  refers  to  the  period  when  the  tool  is  spinning  but  is  not  in  contact  the 
work  piece.  Figure  3-2  shows  a typical  idle  segment.  The  most  notable  features  during  this 
state  will  be  the  radial  profile  of  the  spindle  shaft.  This  signal  can  be  used  to  calibrate  the 
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two  sensors  - the  two  sensors  should  produce  identical  signals  with  a known  delay.  Also, 
this  signal  will  be  zero  mean,  so  the  signal  base  line  can  be  calculated  at  this  time  to 
remove  any  DC  offset  of  the  probe  amplifiers.  Another  notable  feature,  which  is  shared 
with  tool  throw,  is  its  periodicity. 

Broken  Tooth 

Tool  breakage  is  the  transient  period  in  which  the  tooth  actually  breaks.  It  is  this 
event  that  will  be  detected.  The  most  notable  feature  of  a breaking  tooth  is  the  reduction  in 
force  for  one  of  the  teeth.  That  is,  the  tooth  no  longer  produces  a force,  or  at  least  incurs  a 
reduction  in  force  for  a partial  breakage.  The  tooth  following  the  breaking  tooth  will  be 
given  an  increased  load.  In  addition  to  its  normal  job  of  metal  removal,  it  will  now  have  to 
absorb  the  job  dropped  by  the  preceding  tooth.  If  tooth  force  values  are  compared  to  their 
past  value  at  a one  revolution  delay,  then  large  increases  and  decreased  can  be  observed. 
The  description  of  the  proposed  algorithm  will  begin  by  presenting  a robust  method  in 
which  the  transients  are  observed.  However,  it  is  the  job  of  determining  the  difference 
between  the  small  change  that  is  not  caused  by  tool  breakage  and  the  large  change  that  is 
caused  by  tool  breakage  which  will  prove  the  most  challenging. 
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Runout  and  Tool  Throw 

Runout  is  caused  by  two  primary  causes.  One  is  the  profile  of  the  circumference  of 
the  spindle  shaft  at  which  the  probes  are  located.  Since  this  surface  is  not  perfectly  round, 
a periodic  variation  of  measured  distance  will  be  recorded.  This  profile  is  displayed  in  fig- 
ure 3-2.  Another  cause  is  imbalance  of  the  spindle  and  tool.  These  signals  are  periodic  and 
easily  removed.  The  removal  is  made  easy  since  the  data  is  synchronously  sampled  and 
has  a period  of  one  revolution.  Tool  throw  is  a more  serious  problem  and  may  be  of  two 
types:  axial  and  radial.  Axial  throw  is  caused  by  the  variations  in  the  axial  length  of  each 
tooth.  In  the  experiments  studied  for  this  work,  a face  mill  with  removable  inserts  is  used, 
and  installing  the  inserts  with  good  axial  precision  is  not  difficult.  This  is  accomplished  by 
mounting  a flat  plate  onto  the  face  of  the  tool  and  firmly  seating  each  insert  against  this 
plate.  Additionally,  the  face  of  the  tool  is  responsible  for  machining  a smooth  surface.  This 
causes  the  operator  to  use  care  when  adjusting  the  axial  position  of  each  insert.  Radial 
adjustments  do  not  enjoy  such  fortune  and  can  produce  a significant  force  variation 
between  two  teeth. 

Neither  runout  nor  tool  throw  are  difficult  to  manage  during  steady  state  since  they 
are  periodic  and  can  be  predicted  based  on  history.  Figure  3-3  shows  a typical  signal.  Five 
revolutions  are  shown  for  data  taken  with  an  8 tooth  face  mill  at  25%  radial  immersion. 
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The  first  two  signals  are  the  raw  displacement  measured  in  two  axis.  The  bottom  signal  is 
the  revolution  difference.  The  small  amplitude  shows  the  periodicity  of  the  signal. 

It  is  during  entry  that  the  difficulty  lies.  During  entry  tool  throw  is  not  know,  and 
even  if  it  was  it  would  still  require  a few  revolutions  to  pass  before  the  profile  could  be 
phase-aligned  to  the  data.  A broken  or  missing  tooth  can  be  considered  a severe  case  of 
tool  throw.  This  problem  will  be  handled  as  missing  tooth  identification. 

Revolution  Difference 

Figure  3-4  shows  a segment  of  raw  displacement  data  presenting  three  revolutions  of 
the  spindle  in  the  direction  of  feed  for  25%  immersion  and  8 teeth.  This  figure  will  be  used 
to  explain  the  practical  basis  of  the  basic  algorithm  structure.  Two  consecutive  one-revolu- 
tion periods  are  marked.  As  seen,  this  is  steady  state  milling,  and  little  change  occurs. 
Since  data  is  synchronously  sampled,  the  number  of  samples  per  revolution  is  known  and 
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constant.  In  theory  if  a one  revolution  difference  is  taken,  the  signal  will  be  nullified.  In 
practice,  there  are  small  variations  between  two  consecutive  revolutions,  but  the  changes 
are  small  in  relation  to  the  signal  power  (see  figure  3-3).  A single  tooth  period  is  also 
marked.  There  are  8 such  periods  in  one  revolution.  The  variance  of  amplitude  between 
consecutive  teeth  are  due  to  runout  and  tool  throw.  This  prevents  using  the  amplitude  of 
the  previous  tooth  as  a reference  to  the  amplitude  of  the  current  tooth,  and  explains  why 
the  amplitude  of  the  tooth  one  revolution  back  is  used  as  a reference. 

This  basic  one-revolution  difference  algorithm  is  known  as  a comb  filter  in  digital 
signal  processing  literature.  Equation  3- 1 presents  this  filter  where  N is  equal  to  the  num- 
ber of  samples  per  revolution. 


When  a single  tooth  breaks,  it  will  cease  to  exert  force.  Additionally,  the  following 
tooth  will  encounter  an  increase  in  force.  The  two  features  of  tooth  breakage  are  therefore 
a decrease  in  the  force  followed  by  an  increase  in  the  force.  By  taking  a one  revolution  dif- 
ference, when  the  broken  tooth  is  initially  encountered  the  output  of  the  comb  filter  will  be 
a waveform  equal  to  the  inverted  single  tooth  force.  Since  the  following  tooth  incurs  an 
increase  in  force,  the  output  of  the  comb  filter  will  also  contain  a waveform  similar  to  the 
normal  single  tooth  force.  The  length  of  this  signal  will  be  proportional  to  the  radial 
immersion  angle.  The  force  of  a single  tooth  is  represented  as  (from  chapter  2): 


(EQ  3-1) 


Tooth  Breakage  Transient 


(EQ  3-2) 


where  a masking  function  is  defined  to  account  for  radial  immersion. 


(EQ  3-3) 
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Work  Piece 
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Figure  3-5.  Definition  of  radial  immersion  angle. 


and  rifr  is  the  point  of  entry  and  ne  is  the  point  of  exit.  The  length  of  each  feature  is  equal  to 
the  length  of  tooth  contact.  Figure  3-5  will  be  used  to  clarify  this  point.  The  length  of  con- 
tact, ne-ni ,,  is  the  length  of  a tooth  feature.  The  two  broken  tooth  features  will  have  this 
length,  with  the  first  one  being  negative  and  the  second  one  having  positive  polarity.  Also, 
the  second  feature  will  be  delayed  by  N/NT.  If  the  length  of  contact  is  less  than  N/NT,  then 
the  two  features  will  not  overlap  at  all. 

The  total  force  produced  is  represented  by: 


where  NTis  equal  to  the  number  of  teeth,  which  represents  the  force  signal  prior  to  tooth 
breakage.  For  the  case  of  the  broken  tooth,  total  breakage  will  be  assumed.  That  is,  the 
broken  tooth  will  not  have  any  contact  with  the  workpiece.  In  terms  of  equation  3-4,  one 
of  the  terms  in  the  summation  will  drop  out.  The  tooth  following  the  broken  one  will  have 
its  value  for  St  doubled.  The  effect  of  this  will  vary  depending  on  the  value  of  St,  h*,  and 
the  immersion  angle.  The  force  signal  for  a single  broken  tooth  can  be  modeled  as 


Using  a one-revolution  difference,  the  signal  in  the  first  revolution  after  the  breakage 
will  be  defined  by 


Z/,(»-£o 
1 = 0 r 


(EQ  3-4) 


(EQ  3-5) 


(EQ  3-6) 
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which  can  be  simplified  to: 


(EQ  3-7) 


A significant  point  of  equation  3-7  is  that  there  are  two  breakage  features  which  may 
overlap  depending  on  radial  immersion.  The  shape  of  the  damage  features  (i.e.  the  plots  of 
multi-tooth  one-revolution  differential  force  vs.  time  after  breakage)  are  graphically 
depicted  in  figure  3-6.  All  plots  are  for  up  milling  with  nb  set  to  zero.  The  plots  are  shown 
for  six  values  of  ne.  These  plots  were  produced  through  simulation  of  equation  3-7  using 
typical  values  obtained  in  chapter  2.  These  signals  were  filtered  using  a moving  average 
with  a window  of  one  tooth  period  (N/NT)  and  normalized  by  DC  so  that  they  are  only 
dependent  on  the  radial  immersion.  Each  plot  contains  one  revolution,  or  120  points. 
These  plots  show  the  effect  of  partial  feature  overlap.  That  is,  the  change  in  feature  size  in 
relation  to  radial  immersion.  The  simulation  used  8 teeth,  so  the  delay  between  the  nega- 
tive and  positive  feature  (N/NT)  is  15  points. 


In  the  implementation  of  the  breakage  detector,  some  practical  issues  had  to  be 
addressed,  such  as  improved  signal  to  noise  ratio.  The  first  step  is  to  low  pass  filter  each  of 
the  sensor  channels.  The  chosen  approach  uses  a moving  average  with  a window  equal  to 
one  tooth  period  ( AWVj ). 


This  gives  an  output  that  is  equal  to  the  average  force  in  any  given  tooth  period  for 
each  of  the  two  sensor  signals.  As  explained  in  chapter  2,  these  two  signals  represent  the 
orthogonal  decomposition  of  the  actual  complex-valued  force  signal.  A simplification  is 
used  to  combine  the  two  channels  into  one  force  signal.  This  simplification  is  to  use  the 
magnitude  of  the  two  channels.  This  method  ignores  the  phase  of  the  signal. 


Algorithm  for  Feature  Extraction 


(EQ  3-8) 
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di  = V (*;) 2 + O;)2  (EQ  3-9) 

This  signal  is  processed  by  a modified  revolution  difference  to  extract  the  breakage 

transient  described  in  equation  3-7.  Two  goals  are  designed  into  this  algorithm.  The  first  is 
to  reduce  the  effects  of  noise.  This  is  accomplished  by  replacing  the  value  of  the  displace- 
ment one  revolution  back  with  an  average  of  values  at  one-revolution  increments  into  the 
past.  The  second  is  to  increase  the  window  of  observable  features.  In  a strict  difference 
such  as  equation  3-1,  breakage  features  will  only  be  observable  during  the  first  revolution 
after  breakage.  The  temporal  period  of  observability  is  increased  by  replacing  the  estimate 
of  the  force  one  revolution  back  with  an  estimate  of  the  force  further  in  the  past.  The  mod- 
ified revolution  difference  algorithm  is  known  as  the  RORPA  filter  [29], 

ri  = di-j'Ldi-u+P)N  (EQ  3-10) 

j~  o 

where  R is  the  number  of  values  averaged  and  p is  the  delay.  By  increasing  p,  the  number 
of  revolutions  in  which  the  damage  features  are  observable  will  increase.  The  increase  in 
the  observable  window  allows  the  use  of  a syntactic  classifier  to  reduce  false  positive 
errors. 

The  increase  in  the  observable  window  produces  an  output  that  follows  the  slope  of 
the  slow  wave.  The  output  of  the  RORPA  through  entry  (figure  3-7)  shows  this  effect.  By 
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taking  a modified  median  of  the  RORPA  output  and  then  subtracting  the  median  output 
from  the  RORPA  output,  the  effect  of  slow  wave  slope  can  be  eliminated. 

The  median  is  taken  from  a set  of  points  such  that 


m-  = Median  J x-,x 


N ’ •••’  ■*  n 


(EQ  3-11) 


where  N/NT  denotes  the  spacing  between  adjacent  teeth.  The  output  of  figure  3-7  was  pro 


duced  for  k=  5. 


Threshold  Estimation 

In  order  to  make  a decision  regarding  the  presence/absence  of  breakage,  threshold- 
ing is  necessary.  It  is  necessary  to  predict  the  size  of  the  features,  which  are  defined  by 
equation  3-7,  to  obtain  the  correct  threshold  setting  for  the  detector.  The  results  of  the  low 
pass  filter  (equation  3-8)  yields 
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By  applying  a comb  filter 
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(EQ  3-14) 


an  estimate  of  I F( 0) I is  produced.  In  chapter  2 F(0)  was  shown  to  be  equal  to  NTFp(0).  So, 
an  estimate  of  Fp( 0)  is  obtained  in  this  fashion. 

This  breakage  feature,  under  the  constraints  of  equations  3-8  and  3-9,  will  have  a 
peak  amplitude  equal  to  NTFp(0)  as  predicted  by  equation  3-7.  It  is  this  feature  that  is 
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extracted  by  equation  3-14.  When  the  immersion  increases  beyond  N/NTup  to  its  maxi- 
mum of  N/2,  the  two  features  will  overlap.  Under  the  above  analysis  the  peak  of  the  fea- 
tures will  decrease  from  NjFp(0).  This  is  shown  in  figure  3-8.  For  this  figure  there  are  8 
teeth  and  120  points  per  revolution.  The  value  of  n ^ is  set  to  zero.  The  horizontal  axis  of 
figure  3-8  represents  ne.  That  is,  the  figure  covers  from  0%  immersion  (left  side)  to  full 
immersion  (right  side).  The  dashed  line  corresponds  to  the  size  of  the  missing  tooth  symp- 
tom. The  solid  line  corresponds  to  the  feature  size  for  the  tooth  following  the  broken  tooth. 
The  features  have  been  normalized  by  NTFp(0).  When  overlap  of  features  begin  (ntf=15), 
normalized  size  decreased  from  1 to  a low  value  of  0.3. 

Until  a reliable  method  is  found  to  predict  radial  depth,  the  threshold  is  set  to  catch 
the  smallest  features.  The  feature  extraction  routine  has  the  responsibility  of  providing  a 
signal-to-noise  ratio  that  will  meet  this  requirement.  A flow  diagram  for  the  transient 
detector  is  shown  in  figure  3-9. 
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Tool  Throw 

By  assuming  negligible  edge  effects,  equation  3-4  can  be  adjusted  to  include  tool 
throw.  The  new  equation  is 


*r-‘ 

H(z)  = (i)z  Nt  (EQ  3-15) 

; = o 

where  t(i)  denotes  an  perturbation  for  tooth  j such  that 

nt-  I 

X *')  = nt  (EQ  3-16) 

i = 0 

The  variance  of  t(i)  can  be  adjusted  according  to  the  desired  severity  of  tool  throw. 

In  accordance  with  the  analysis  of  chapter  2,  the  observable  values  for  an  unbroken  tool 
with  no  tool  throw  will  remain  unchanged.  This  is  because  the  observable  values  are  at 
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At  these  values  equation  3-15  reduces  to 


(EQ  3-17) 
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which  is  identical  for  the  variance  of  t(i)  equal  to  zero. 

Under  the  criterion  of  equation  3-16,  tool  throw  does  not  affect  spectral  values  at 
DC,  the  tooth  frequencies,  and  its  harmonics.  At  the  other  spectral  values,  previously 
unobservable  components  of  the  single  tooth  frequency  will  become  observable,  with  the 
degree  of  observability  depending  on  the  variance  of  t(i).  This  means  chat  the  observable 
portions  of  the  single  tooth  force  remain  observable  in  the  presence  of  tool  throw.  Of 
immediate  importance  to  tool  breakage  detection  is  that  tool  throw  does  not  affect  the 
threshold  value. 
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Feature  Interpretation 

In  practice  there  will  be  features  that  meet  the  threshold,  but  are  not  produced  by  a 
broken  tooth.  It  is  possible  to  analyze  these  features  to  reduce  false  positive  errors.  Nega- 
tive features  are  attributed  to  a broken  tooth.  Positive  features  are  attributed  to  the  extra 
load  taken  by  a tooth  following  a broken  tooth.  The  negative  features  will  be  referred  to  as 
primary  features.  The  positive  features  will  be  referred  to  as  secondary  features.  Their  role 
is  to  support  primary  features,  and  they  have  no  meaning  on  their  own.  This  is  the  first  of 
two  rules  for  feature  interpretation.  That  is,  a secondary  feature  that  follows  a primary  fea- 
ture by  a one  tooth  delay  provides  positive  evidence  that  the  primary  feature  is  indeed  an 
indicator  of  a broken  tooth.  A secondary  feature  that  does  not  meet  this  requirement  is  dis- 
carded. The  second  rule  stipulates  that  a primary  feature  that  follows  another  primary  fea- 
ture by  a delay  of  one  revolution  provides  positive  evidence  that  the  leading  primary 
feature  is  an  indicator  of  a broken  tooth. 

Once  two  supporting  features  are  found,  breakage  is  declared.  In  the  standard  case 
this  involves  finding  a primary  symptom  followed  by  a secondary  symptom.  In  cases  of 
deep  radial  immersion,  the  secondary  symptom  is  harder  to  observe  (figure  3-6).  This  is 
where  the  second  rule  becomes  significant.  It  requires  two  supporting  primary  symptoms 
in  cases  where  the  secondary  symptom  can  not  be  observed. 

The  feature  extraction  algorithm  introduces  a delay  equal  to  one-half  revolution 
(extracting  F(0))  plus  one-half  tooth  period  (tooth  period  averaging).  Feature  interpreta- 
tion will  introduce  a one-tooth  period  delay  when  the  secondary  symptom  is  present  and  a 
one-revolution  delay  when  the  secondary  feature  can  not  be  extracted. 

Tooth  Breakage  Test 

Verifying  the  tool  breakage  algorithm  introduces  some  procedural  difficulties.  The 
probability  of  a tooth  breaking  during  normal  milling  are  very  low.  This  has  led  to  having 
no  recorded  instances  of  natural  breakage.  Simulated  data  is  very  helpful  during  algorithm 
design,  but  real  data  is  required  for  absolute  proof.  To  aid  in  testing,  the  probability  of  tool 
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breakage  needed  to  be  increased.  The  first  step  is  to  mill  with  higher  than  normal  chip 
loads.  The  second  step  is  to  artificially  weaken  one  or  more  of  the  teeth.  Following  is  a set 
of  test  data  collected  from  induced  tool  breakage. 

Figures  3-10,  3-1 1,  and  3-12  show  results  of  the  signal  processing  after  threshold- 
ing. To  visualize  the  threshold,  the  features  were  divided  by  the  estimated  value  of  F(0). 
All  cuts  were  taken  with  an  8 tooth  face  mill  on  a steel  workpiece  at  400  RPM.  The  value 
of  feed  per  tooth  (Sf)  was  initially  set  to  0.010”  and  gradually  increased  during  the  cut 
until  breakage  occurred.  The  data  was  synchronously  sampled  at  120  points  per  revolu- 
tion. The  following  table  summarizes  the  conditions  for  the  three  examples. 


TABLE  3-1.  Induced  tool  breakage  test. 


Case 

immersion 

axial 

st 

1 

20% 

0.070” 

0.013” 

2 

25% 

0.090” 

0.014” 

3 

25% 

0.080” 

o 

o 

o 

Case  1 and  2 show  the  strength  of  transient  detection  in  steady  state.  In  this  period 
tool  throw  and  runout  are  known  and  removed.  As  seen,  the  signal  to  noise  ratio  at  this 
time  is  very  good.  In  case  three  the  tooth  broke  at  16  revolutions  into  the  cut.  The  initial 
activity  is  due  to  tool  throw.  However,  these  features  lack  the  signature  of  genuine  tool 
breakage,  down-up  spike  pairs  separated  by  one  revolution.  These  algorithms  were  pro- 
cessed with  R equal  to  five  and  p equal  to  one  (equation  3-10);  k equal  to  five  (equation  3- 
11);  feature  threshold  equal  0.3;  and  a requirement  of  two  damage  features. 

Missing  Tooth  Test 

Additional  tool  breakage  test  were  taken  by  performing  cuts  with  a missing  tooth. 
This  test  is  analogous  to  starting  a cut  with  a broken  tooth  or  severe  tool  throw.  This  differs 
from  detection  of  tooth  breakage  in  that  tooth  breakage  produces  a noticeable  transient, 
and  a missing  tooth  does  not.  The  feature  used  to  find  the  missing  tooth  is  the  transition 
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Figure  3-10.  Broken  tooth  processing  for  test  case  1 . 
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Figure  3-11.  Broken  tooth  processing  for  test  case  2. 
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Figure  3-12.  Broken  tooth  processing  for  test  case  3. 
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from  the  missing  tooth  to  the  following  tooth  (figure  3-6).  The  significance  of  this  is  that 
the  missing  tooth  will  produce  a low  force  value  and  the  successive  tooth  will  have  a high 
force,  which  means  that  there  will  be  a large  change  in  amplitude  between  two  teeth.  Also, 
the  use  of  this  tooth  period  difference  reduces  the  effect  of  tool  throw.  The  differencing  is 
done  by: 

di  = V*  v (EQ  3-19) 

*T 

The  flow  of  this  algorithm  is  shown  in  figure  3-13.  The  two  raw  data  signals  are 
averaged  by  equation  3-8  to  produce  an  average  displacement  per  tooth  period.  This  signal 
is  processed  by  equation  3-19  to  produce  the  change  in  amplitude  between  adjacent  teeth. 
By  processing  this  signal  by  the  RORPA  (equation  3-10),  the  runout  during  idle  will  be 
removed.  This  will  leave  the  tool  throw  between  adjacent  tooth  periods  present  during 
entry.  The  magnitude  of  this  signal  is  normalized  by  F(0)  to  reduce  the  effects  of  feed  rate 
and  spindle  speed. 

Difference  signals  are  sensitive  to  rapid  changes  which  means  the  algorithm  will  be 
sensitive  to  noise  and  sudden  entry.  Because  of  this,  it  is  required  that  two  features  sepa- 
rated by  one  revolution  be  present  before  breakage  is  declared. 

117  data  records  were  used  to  verify  this  algorithm.  All  records  were  taken  with  an  8 
tooth  face  mil  on  cast  iron.  This  data  set  includes  90  records  that  were  used  by  Yoon  [29]. 
52  of  the  records  were  recorded  with  one  tooth  removed  from  the  tool.  All  algorithm 


54 


parameters  remain  the  same,  except  the  threshold  is  now  set  to  one.  The  following  table 
summarizes  the  test  data. 


TABLE  3-2.  Test  data 

summary. 

Good  Tool 

Broken  Tool 

Up  Milling 

53 

23 

Down  Milling 

29 

12 

Total 

82 

35 

There  were  no  false  negative  errors.  That  is,  all  test  records  for  broken  tools  were 
correcdy  identified.  Four  of  the  good  tool  records  were  incorrectly  identified  as  broken. 
This  results  in  100%  detection  with  5%  false  positive  errors.  The  algorithm  introduces  a 
delay  of  one-half  revolution  (extracting  F(0))  plus  one-half  tooth  period  (tooth  period 
averaging).  Feature  interpretation  adds  a delay  of  one  revolution. 

Figure  3-14  presents  two  cases:  one  with  good  teeth  and  the  other  with  one  tooth 
removed.  These  cases  were  taken  on  cast  iron  for  100%  immersion  and  an  axial  depth  of 
0.090”.  The  features  were  normalized  by  F(0)  to  show  the  prominence  of  the  missing 
tooth.  The  normalized  features  show  the  prominence  of  the  missing  tooth  and  how  the 
missing  tooth  features  are  separated  by  one  revolution. 

Figure  3-15  presents  the  results  from  a record  that  produced  a false  positive  error. 
These  data  were  recorded  for  3375  RPM  down-milling  with  axial  depth  of  0.05”,  feed  per 
tooth  of  0.01  , and  50%  radial  immersion.  The  figure  shows  the  unprocessed  data  for  the  x 
and  y channels.  The  output  of  tooth  period  averaging  is  also  shown  (x  and  y).  A first 
noticeable  feature  is  that  there  is  an  unknown  variability  during  idle  (prior  to  entry).  Data 
is  normally  periodic  over  one  revolution,  but  since  this  did  not  hold  true,  the  algorithm 
detected  a missing  tooth  before  entry.  Four  points  are  marked  that  exceeded  the  threshold 
dunng  entry  (p}  through^).  The  point p2  followed Pl  by  72  points  (one  revolution), 
therefore,  p2  was  recognized  as  an  indicator  for  a missing  tooth.  The  point  p4  follows  p3 
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Figure  3-15.  Missing  tooth  false  positive  detection. 
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by  72  points,  so  it  is  also  recognized  as  an  indicator  of  a missing  tooth.  However,  p3  fol- 
lows p2  by  a delay  of  88  points,  which  means  that  a missing  tooth  was  detected  at  two  dif- 
ferent locations  on  the  tool.  The  variance  from  a one-revolution  period  during  idle  is  the 
main  cause  for  the  false  positive  detections.  The  reason  of  this  is  unknown  since  these  par- 
ticular data  were  recorded  over  five  years  ago,  and  such  variations  are  unexpected  in  syn- 
chronous sampled  displacement  data. 


Summary 

Two  algorithms  were  presented.  The  first  one  shows  a fast  method  of  extracting  the 
tooth  breakage  transient.  The  second  algorithm  is  targeted  at  detecting  a missing  tooth  or 
tooth  breakage  during  the  first  revolution.  Both  algorithms  performed  well,  except  that 
tool  breakage  was  limited  to  tests  in  which  breakage  was  artificially  induced.  In  the  fol- 
lowing chapters  a model  by  which  these  alarm  detection  systems  can  be  integrated  into  a 
system  for  comprehensive  supervision  will  be  presented. 

Both  detection  algorithms  share  two  characteristics.  Both  are  normalized  by  F(0). 
This  normalization  removes  the  effects  of  all  parameters  except  radial  immersion.  This 
normalization  is  responsible  for  producing  features  within  a known  range.  Both  algo- 
rithms also  use  a syntactic  classifier  that  require  that  two  damage  features  be  found  before 
detection  is  declared.  This  classifier  finds  features  that  are  caused  by  the  same  tooth,  and 
significantly  reduces  the  number  of  false  positive  errors. 


CHAPTER  4 

DISTRIBUTED  SUPERVISION  SYSTEM 
Necessity  for  Supervision 

The  traditional  machine  tool  control  structure  contains  three  modules:  the  machine 
tool,  CNC,  and  operator.  Supervision  is  performed  by  the  operator.  Judgements  concern- 
ing the  condition  of  the  tool  and  stability  of  the  process  are  assessed,  and  used  in  choosing 
a corrective  course  of  action.  This  enhances  the  standard  function  of  the  CNC,  which  con- 
trols the  position,  direction,  and  speed  of  the  tool  and  workpiece.  The  shortcoming  of 
operator  supervision  is  that  the  feedback  path  is  slow. 

Automation  will  reduce  the  feedback  delay,  and  allow  process  updates  to  occur 
more  rapidly.  It  is  proposed  that  supervision  follows  the  structure  of  a loosely-coupled 
system.  Such  a system  allows  for  supervision  to  be  decomposed  into  several  autonomous 
units.  Additional  features  are  resource  sharing  and  computational  scaling. 

Supervision  Model 

A general  purpose  distributed  system  is  characterized  by  a set  of  separate  computers 
that  are  capable  of  autonomous  operation,  linked  by  a computer  network.The  shared 
resources  needed  to  provide  an  integrated  computing  service  are  provided  by  some  of  the 
computers  in  the  network  and  are  accessed  by  system  software  that  runs  in  all  of  the  com- 
puters. Distributed  systems  of  this  type  are  known  as  loosely-coupled  systems  to  distin- 
guish them  from  other  kinds  of  computer  system  that  can  lay  claim  to  the  title 
distributed”.  A loosely  coupled  system  allows  each  sub-system  to  independently  specify 
its  computational  requirements.  By  allowing  independently  specified  hardware  to  be 
added  to  the  system,  future  needs  can  be  anticipated. 
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Figure  4-1.  Structure  of  monitoring. 


Machine  tool  supervision  is  inherently  parallel,  as  shown  in  figure  4-1.  The  job  of 
supervision  is  to  integrate  monitoring  and  control  methods  to  an  external  CNC.  A variable 
number  of  supervision  sub-systems  are  depicted  inside  the  supervision  block.  Each  sub- 
system operates  independently  in  that  each  is  allocated  sufficient  computational  resources 
to  perform  its  task.  The  number  of  sub-systems  is  also  expandable. 

Figure  4-2  shows  a loosely  coupled  implementation  of  the  supervision  system  from 
figure  4-1.  As  seen,  the  CNC  is  inserted  into  the  distributed  system  by  means  of  an  inter- 
face computer.  For  this  implementation  the  CNC  is  essentially  closed,  and  Chapter  5 will 
present  the  details  of  how  this  CNC  was  integrated  into  the  distributed  supervision  system. 
A more  long  term  solution  might  be  to  redesign  the  CNC  from  the  ground  up  so  that  it 
could  be  more  tightly  integrated  with  a supervisor  [57,58],  However,  interfacing  the  CNC 
to  an  external  supervisor  allows  existing  hardware  to  be  utilized.  The  key  to  integrating  the 
CNC  is  to  provide  a separate  data  path  for  sensor  input.  Supervision  requires  nontradi- 
tional  data  such  as  tooth  force,  and  the  computational  resources  of  the  CNC  do  not  allow 
for  extensive  task  allocation  beyond  the  manufacturer’s  original  function  specifications. 
Figure  4-2  also  shows  a shared  bus  structure  for  the  computer  network. 
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Design  Methodology 

In  designing  a system  it  is  often  convenient  to  first  describe  the  basic  functional 
units.  A common  means  of  achieving  this  is  to  use  the  notion  of  objects  [59],  An  object 
comprises  a set  of  defined  states,  a current  state,  and  a set  of  operations.  This  notion  pro- 
vides a structure  by  which  the  basic  units  of  a system  can  be  encapsulated  through  abstract 
data  typing.  Abstract  data  types  describe  the  representation  and  behavior  of  objects,  and 
provide  a clear  separation  between  the  external  interface  of  a data  type  and  its  internal 
implementation.  The  notion  of  objects  is  a modeling  concept  which  has  no  relation  to 
choice  of  programming  language.  Object  oriented  programming  languages  were  intro- 
duced after  object  oriented  design  was  found  beneficial  for  modeling. 

The  notion  of  objects  applies  to  the  structure  of  a loosely-coupled  system  in  the  fol- 
lowing way.  This  system  follows  a service  model  in  which  objects  are  managed  by 
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servers,  and  clients  make  requests  for  operations  on  objects  through  an  interprocess  com- 
munications facility.  Therefore,  each  node  in  the  distributed  system  contains  a service  base 
that  provides  inter-node  communication  and  a library  of  support  objects  that  define  tasks 
that  will  be  requested  by  remote  clients.  This  manner  of  functional  grouping  provides  a 
level  of  transparency  that  is  created  though  the  service  base  and  the  abstract  data  type 
capability  of  objects.  The  client  is  not  aware  that  the  operation  is  remote,  and  the  support 
object  is  not  aware  that  its  client  is  remote. 

The  definition  of  an  object  contains  no  temporal  notions.  Therefore,  threads  of  con- 
trol are  defined  to  introduce  a partial  ordering  of  events  in  the  distributed  system.  A thread 
of  control  is  a totally  ordered  set  of  events  defined  by  a programmer.  A distributed  system 
will  consist  of  multiple  threads  of  control  which  operate  in  parallel.  Threads  follow  two 
definitions.  Two  threads  operating  on  different  computers  will  operate  concurrently  and 
wili  not  share  resources  such  as  memory.  However,  multiple  threads  are  also  supported 
within  a single  computer.  These  threads  are  capable  of  using  shared  memory. 

Threads  operating  on  disjoint  computers  define  the  distribution  of  processing.  How- 
ever, it  is  the  capability  of  having  multiple  threads  within  a computer  coupled  with  a 
library  of  support  objects  that  produce  the  service  base  that  handles  operations  requested 
by  remote  clients,  and  provides  for  easy  extension  to  the  library  of  support  objects. 

The  master  computer  is  a NeXT  workstation.  It  is  the  master  in  the  sense  that 
actions/results  that  are  global  in  nature  will  flow  from/to  this  node.  The  NeXT  computer  is 
based  on  the  MACH  operating  system.  This  operating  system  provides  support  for  multi- 
threaded applications.  It  allows  multiple  threads  of  control  to  share  a single  CPU. 
Although  these  threads  are  executing  on  a single  CPU,  they  will  operate  in  parallel  with 
the  threads  that  execute  on  other  computers.  Multi-threaded  applications  should  not  be 
confused  with  task  switching  and  multi-processing.  In  a task  switching  situation  the  CPU 
is  shared  between  multiple  processes  in  a fixed  manner.  This  is  accomplished  by  predefin- 
ing a schedule  order  and  time  allotment  for  each  process.  A multi-processing  system  also 
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shares  the  CPU  between  multiple  processes.  The  operating  system  will  choose  a job  from 
a job  pool  based  on  its  CPU  scheduling  algorithm.  Eventually,  the  job  may  have  to  wait  for 
something,  such  as  a data  from  the  user  or  network.  This  job  will  be  tagged  as  blocked  and 
another  job  will  be  chosen.  The  blocked  job  will  not  be  returned  to  the  job  pool  until  the 
blocking  I/O  operation  is  completed.  In  an  operating  system  such  as  MACH,  multi-pro- 
cessing is  handled  in  the  above  manner  except  that  each  process,  called  a task,  can  have 
multiple  threads  of  execution.  Threads  are  scheduled  and  blocked  in  the  same  manner  as 
task’s,  except  that  a thread  is  a lightweight  version  of  a task  which  provides  for  faster  con- 
text switching.  The  increase  in  context  switching  times  is  accomplished  since  threads 
within  a task  are  not  protected.  That  is,  they  operate  on  shared  resources  such  as  memory. 

Support  Objects 

The  blocks  in  figure  4-3  represent  computational  engines,  and  the  ovals  represent 
threads  of  control.  These  include  a NeXT  (UNIX)  work  station,  an  Intel  80286  based  PC, 
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two  Motorola  DSP56001s,  and  a CNC.  The  NeXT  and  the  286  PC  each  have  one  major 
thread  of  control  designated  as  main.  They  also  contain  additional  threads  to  maintain  data 
flow.  These  minor  threads  are  network  servers  (ns)  and  data  servers  (ds).  These  threads  are 
interrupt  driven  so  that  they  steal  cycles  from  the  main  threads  only  when  necessary  to 
receive  and  transmit  data.  Data  servers  and  network  servers  are  examples  of  support 
objects.  An  additional  class  of  support  objects  are  display  servers.  These  objects  are 
responsible  for  taking  data  from  data  servers  and  converting  it  to  a presentable  form. 

Network  Resources 

The  CNC  runs  multiple  threads  by  means  of  task  sharing.  Its  structure  will  be  dis- 
cussed in  chapter  5.  The  lower  thread,  called  the  control  thread,  represents  the  heart  of  the 
CNC.  This  is  where  the  part  program  is  interpreted  to  control  the  machine  tool  for  produc- 
ing a desired  part.  The  upper  thread  represents  the  interface  to  the  CNC  control.  These  two 
threads  communicate  through  shared  memory.  That  is,  the  interface  thread  can  read  and 
write  values  to  memory  that  will  be  later  interpreted  by  the  control  thread. 

The  286  PC  provides  the  CNC  interface  thread  as  a network  resource.  Since  this  task 
is  not  intensive,  it  also  provides  a DSP  as  a network  resource.  The  DSP  system  contains  a 
fast  processor  optimized  for  signal  processing  applications.  It  also  contains  on  board  data 
acquisition  so  that  sensor  data  can  be  acquired  and  processed  with  minimal  delay.  Its  par- 
ticular purpose  is  for  processing  displacement  data  for  detection  of  tool  breakage. 

Instantiation  Protocol 

There  is  an  inherent  data  flow  structure  implied  in  figure  4-3.  In  this  structure  the 
data  flow  is  a message  from  a supervision  sub-system  to  the  master.  This  message  initiates 
a series  of  actions  on  the  master  in  the  following  fashion.  The  network  server  monitors  the 
network  for  requests  for  new  data  connections.  When  the  network  server  accepts  a new 
connection,  the  first  value  that  it  expects  is  an  identifier  for  the  type  of  data.  Based  on  this 
data  type,  it  then  queries  the  collection  of  data  server  classes  to  choose  and  instantiate  the 


64 


appropriate  server.  This  server  is  activated  by  spawning  a new  thread  controlled  by  this 
object.  Upon  activation  the  data  server  will  search  for  an  existing  display  object  that  will 
accept  its  data.  The  supervision  system  maintains  a listing  of  known  protocols  and  the  cor- 
responding data  server  object  for  each.  This  method  of  handling  data  connections  was 
implemented  to  allow  easy  integration  of  new  data  protocols  and  to  allow  the  number  and 
type  of  data  connections  to  be  determined  dynamically. 

Consider  a new  connection  for  the  display  of  raw  displacement  data.  The  NeXT 
would  instantiate  a data  server  that  is  capable  of  managing  raw  displacement  data.  This 
data  handler  would  then  search  for  a display  server  that  has  advertised  itself  as  being  capa- 
ble of  accepting  raw  displacement  data. 

Dead  Lock  Avoidance 

In  the  supervisory  system  multiple  threads  provide  a convenient  method  of  effi- 
ciently handling  I/O  operations,  as  well  as  for  modeling  parallel  operations.  Instead  of 
using  a single  thread  that  would  continuously  check  the  network,  data  connections,  and 
keyboard  for  input,  a thread  can  be  assigned  to  each  task  and  will  only  be  activated  when 
input  is  available  or  output  can  be  performed.  Threads  within  a task  can  use  shared  mem- 
ory to  communicate.  This  is  important  for  transfer  of  data  between  data  servers  and  dis- 
play servers.  In  this  configuration  the  data  server  produces  data  that  is  later  consumed  by 
the  display  server.  This  relationship  is  known  as  the  producer/consumer  model  in  operat- 
ing systems  literature. 

The  producer  and  consumer  must  be  synchronized  so  that  the  consumer  does  not  try 
to  consume  items  which  have  not  yet  been  produced.  In  this  model  data  servers  are  pro- 
ducers and  display  servers  are  consumers.  Lying  between  them  is  a circular  buffer  and  a 
set  of  buffer  operators  that  carefully  synchronizes  the  communications  so  that  the  buffer 
indices  always  represent  a valid  state. 
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Message  Passing  Protocol 

A combination  of  a message  passing  communication  model  coupled  with  an  object 
oriented  distributed  system  provides  a communications  model  that  is  extensible  and  flexi- 
ble. The  key  to  this  is  that  each  message  begins  with  a type  id  that  is  used  to  instantiate  a 
new  object  to  handle  the  message.  The  NeXT  station  maintains  a list  of  message  id’s  and 
corresponding  objects.  Examine  the  following  file: 


l):MT_KAW_L)lSP:raw  disp:M  TStandard 
l:MT_AVG_DISP:avg  disp:MTStandard 
2:MT_SOUND:sound:MTSound 
3:MT_SPECTRUM:spectrum:MTSpectrum 
4: MT_R AW_C APT : raw  capture:MTRawCapt 


Figure  4-4.  Message  ID  to  object  class  mapping. 


This  particular  excerpt  specifies  five  message  types  and  the  corresponding  object  for 
its  data  handler.  Each  line  contains  four  fields  separated  by  the  character.  Although  this 
may  initially  appear  cryptic,  this  format  is  easily  parsed  by  a computer.  The  first  field 
specifies  the  message  id  number.  The  second  field  specifies  an  internal  label  name.  This 
label  is  used  internally,  and  only  needs  to  be  unique.  The  third  field  specifies  an  external 
label.  The  external  label  is  used  to  identify  the  data  display  to  the  operator.  The  fourth  field 
is  the  name  of  an  object  that  knows  how  to  handle  the  specified  type  of  data. 

As  mentioned,  each  message  begins  with  an  id  that  is  used  to  instantiate  an  appro- 
priate object.  This  id  is  stripped  off  by  the  network  server  and  used  to  instantiate  the 
appropriate  data  server.  The  remainder  of  the  message  is  then  passed  on  to  the  new  object. 
Although  each  message  type  is  fully  independent  at  this  time,  the  above  examples  share 
several  attributes.  This  common  structure  was  included  by  using  the  inheritance  feature  of 
the  Objective  C programming  language.  Inheritance  allows  for  an  object  to  “inherit”  the 
attributes  from  another  object.  The  four  objects  listed  in  figure  4-4  actually  lie  in  a three 
level  hierarchy.  Correspondingly,  the  five  messages  lie  in  a three  level  hierarchy  (figure 
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Figure  4-5.  Data  sever  hierarchy. 


fypeaer  struct  _M1  Standard  In  lo  

shoS  format;  /*  tTT'5' <displacement'  «c-*' 

J^MTStandardlnfo;  °f  “ the  data  streara  *' 


typedef  struct  _MTsyncInfo  { 

7*  saniPIes  Per  revolution  */ 

1 MTSoundlnfo; 

typedef  struct  _MTfixedInfo  { 

short  samp_rate;  /*  sampling  rate  */ 

} MTSoundlnfo; 

typedef  struct  _MTspectrumInfo  { 

i\°rTeUm_P0mtS;  7*  number  of  spectral  points  */ 
| M 1 Spectrumlnfo; 

typedef  struct  _MTcaptureInfo  { 

fMT&pm rnfofo  'e"®h  °f  Capture  segment  *' 


Figure  4-6.  Basic  building  blocks  for  message  format. 


4-5).  Also  included  in  the  hierarchy  is  encapsulation.  Attributes  common  to  a group  of 
message  types  are  contained  within  a single  declaration.  Additionally,  methods  for  operat- 
ing  on  the  common  attributes  are  encapsulated  with  the  attributes. 

The  basic  attributes  are  listed  in  figure  4-6.  These  are  data  stntcture  definitions 
expressed  in  the  C programming  language.  The  message  definitions  constructed  from 
these  are  given  in  figure  4-7.  All  message  types  begtn  wtth  the  standard  info  comprised  of 
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typedef  struct  _M  I RawDispMsg  { 
MTStandardlnfo  info; 

} MTRawDispMsg; 

typedef  struct  _MTAvgDispMsg  { 
MTStandardlnfo  info; 

} MTAvgDispMsg; 

typedef  struct  _MTSoundMsg  { 
MTStandardlnfo  info; 
MTSoundlnfo  sound; 

} MTSoundMsg; 

typedef  struct  _MTSpectrumMsg  { 
MTStandardlnfo  info; 
MTSoundlnfo  sound; 
MTSpectrumlnfo  spect; 

} MTSpectrumMsg; 

typedef  struct  _MTRawCapture  { 
MTStandardlnfo  info; 
MTCapturelnfo  length; 

} MTRawCapture; 


Figure  4-7.  Hierarchical  message  structure. 


a type  identifier,  data  format  type,  and  the  number  of  channels.  The  type  identifier  is 
always  stripped  off  of  the  message  and  used  to  instantiate  a data  server.  Data  servers  share 
the  same  hierarchy  as  figure  4-5.  Just  as  all  messages  inherit  the  attributes  of  MTStan- 
dardlnfo, all  data  server  objects  will  inherit  the  code  to  parse  and  make  decisions  based  on 
the  standard  information  (inheritance  and  encapsulation).  The  basic  information  that  is 
common  is  the  data  format  for  each  sample  and  the  number  of  data  channels. 

The  standard  definition  is  then  split  into  two  sub-classes.  The  first  class  is  for  syn- 
chronous sampling,  and  the  other  is  for  fixed-rate  sampling.  Each  of  these  share  the  stan- 
dard definitions  and  operators,  but  deviate  in  how  the  sampling  rate  is  handled.  Both  of 
these  message  types  indicate  the  connection  of  a data  stream.  A data  stream  is  a continu- 
ous flow  of  data  with  an  indefinite  length.  The  first  sub-class  of  this  is  for  spectral  data. 
Spectral  data  requires  a window  length  to  indicate  the  number  of  points  in  each  spectrum 
estimation.  However,  the  flow  of  data  segments  is  indefinite  in  length.  Capture  data 
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deviates  from  the  continuous  flow  definition.  Capture  data  represents  a data  connection  for 
which  the  continuous  flow  of  data  is  not  of  interest.  Instead,  the  data  is  only  desired  when 
an  event  of  interest  (such  as  tool  breakage)  occurs.  Therefore,  capture  data  is  finite  in 
length. 

Control  of  Subsystems 

Data  streams  are  implemented  for  two-way  communication.  Although  streams  are 
initiated  from  the  sub-system  to  the  master,  this  connection  also  allows  for  messages  to  be 
sent  from  the  master  to  the  sub-system.  At  the  low  level  of  control,  this  channel  is  used  to 
acknowledge  receipt  of  data  and  request  re-transmissions  of  corrupt  or  lost  data.  This 
channel  is  also  used  to  pause,  resume,  and  stop  the  data  flow,  as  well  as  initiating  data  cap- 
ture for  capture  connections. 

Dynamic  Thread  Allocation  with  MACH 

Although  the  PC/AT  is  logically  modeled  as  multi-threaded,  these  threads  are  stati- 
cally defined  through  the  use  of  hardware  interrupts.  Incoming  data  from  the  network  will 
generate  an  interrupt  that  will  activate  the  networking  software  which  will  then  forward 
the  data  to  the  appropriate  data  server.  The  DSP  card  on  the  PC/AT  also  functions  in  this 
respect.  These  meet  the  requirements  for  threads  in  the  sense  that  resources  are  shared, 
with  the  main  resource  being  memory.  Since  preemptive  task  switching  occurs  through  the 
interrupt  priority  level,  care  must  be  taken  in  assigning  priority  levels  and  in  ensuring  that 
the  interrupt  tasks  are  short  in  duration. 

Implementation  of  threads  with  the  MACH  operating  system  is  more  complete.  The 
MACH  operating  system  maintains  a table  of  threads  for  each  task.  Threads  in  this  table 
can  be  created  and  destroyed  dynamically  under  program  control.  Unlike  the  PC  where 
threads  will  execute  until  completion  or  until  a interrupt  of  higher  priority  occurs,  MACH 
threads  are  executed  for  a fixed  amount  of  time,  each  having  its  turn.  The  thread  that  is 
currently  in  use  is  called  the  active  thread.  The  remaining  threads  fall  into  two  groups.  One 
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group  will  be  the  threads  which  are  not  currently  executing,  but  are  capable  of  executing. 
These  threads  are  called  suspended.  The  final  set  of  threads  are  those  which  are  incapable 
of  execution.  These  threads  are  called  blocked. 

The  active  thread  will  execute  until  its  processor  time  allotment  has  expired,  it  is 
blocked,  or  it  voluntarily  yields  the  processor.  The  next  thread  will  then  be  chosen  from 
the  pool  of  suspended  threads.  This  choice  is  made  by  priority.  All  threads  are  assigned  a 
base  priority  level.  As  a thread  waits  for  the  processor,  its  priority  level  increases.  The  base 
priority  level  allows  an  implied  percentage  of  processor  time  to  be  allotted  to  each  thread. 
Although  priority  assignment  is  useful,  scheduling  can  be  more  precisely  controlled 
though  blocking. 

Threads  can  be  blocked  for  a variety  of  reasons.  In  the  supervision  system  threads 
are  generally  blocked  while  waiting  for  data  from  the  network.  This  blocked  state  is 
achieved  by  requesting  data  from  the  network.  If  no  data  is  available,  then  the  thread  will 
automatically  be  blocked.  The  block  will  then  be  removed  when  data  is  available.  Since 
receipt  of  data  is  ultimately  initiated  through  hardware  interrupts,  these  blocking  restric- 
tions are  efficiently  removed.  Blocking  based  on  network  communications  is  implemented 
at  the  system  level. 

Since  threads  share  resources  such  as  memory,  input  devices,  and  output  devices, 
methods  for  synchronization  must  be  provided.  Synchronization  is  performed  through 
software  locks  called  mutex  variables.  Mutex  variables  are  carefully  implemented  by 
MACH  such  that  when  a lock  is  requested  on  the  mutex  variable,  it  will  only  succeed  if  no 
previous  lock  request  has  been  granted.  Additionally,  if  multiple  threads  simultaneously 
request  a lock,  only  one  will  succeed.  These  locks  are  used  for  protection  of  critical 
regions  of  the  program. 

User  level  blocks  can  be  implemented  through  what  is  called  a condition  variable  in 
conjunction  with  a mutex  variable.  When  a lock  request  on  a mutex  variable  fails,  the 
thread  can  choose  to  perform  another  task.  However,  if  the  thread  can  not  proceed  without 
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Figure  4-8.  The  ISO  OSI  reference  model. 

accessing  the  critical  region,  then  the  thread  can  place  itself  into  the  list  of  blocked  threads 
by  naming  a condition  variable  that  will  signal  when  the  blocking  condition  is  removed. 
Although  this  method  can  provide  for  more  efficient  scheduling,  one  must  be  careful  to 
ensure  that  there  will  always  be  a non-blocked  thread  available  to  activate  a blocked 
thread. 


Network  Communication  Model 

The  TCP/IP  protocol  implemented  on  top  of  ethemet  was  chosen  for  the  computer 
network.  TCP/IP  is  the  defacto  standard  used  by  UNIX  work  stations  for  communication, 
as  well  as  the  protocol  use  by  the  Internet,  and  ethemet  is  a widely  accepted  network 
medium.  The  protocol  follows  the  ISO  OSI  standard  (International  Standards  Organiza- 
tion for  Open  System  Interface).  TCP/IP  is  a term  that  encompasses  a group  of  protocols. 
These  protocols  include  TCP  (transfer  control  protocol)  [60],  UDP  (user  datagram  proto- 
col) [61],  and  SMTP  (simple  mail  transfer  protocol)  [62],  IP  (Internet  protocol)  [63] 
describes  the  addressing  format  and  the  routing  methods  used  to  communicate  over  wide 
area  networks  (WAN). 

Figure  4-8  shows  the  ISO  OSI  reference  model  [34],  The  model  defines  seven  layers 
that  start  with  low  level  primitives  at  the  bottom  layer.  Each  succeeding  layer  uses  the 
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methods  defined  in  the  lower  layer  to  build  more  sophisticated  tools.  Only  the  lowest  lay- 
ers are  dependent  on  the  particular  network  hardware  used. 

The  application  layer  provides  the  interface  for  users  to  communicate  between  pro- 
cesses on  the  same  machine  or  on  separate  machines.  Common  examples  of  applications 
include  remote  login  (telnet,  rlogin)  and  file  transfer  utilities  (ftp).  It  is  at  this  layer  that  the 
application  programmer  interface  to  the  messaging  system  lies.  This  interface  only 
requires  a destination  address  and  a message  header  as  defined  in  figure  4-7.  The  presenta- 
tion layer  is  responsible  for  packaging  data  into  a standard  format  to  facilitate  data  transfer 
between  machines  of  different  architecture.  A common  example  is  the  external  data  repre- 
sentation (XDR)  tools  developed  by  SUN  Microsystems.  For  the  supervision  system,  the 
data  format  for  the  NeXT  station  was  chosen  as  the  standard,  and  the  PC  based  software 
was  written  to  convert  its  data  format  to  that  of  the  NeXT.  Data  encryption  and  compres- 
sion could  also  be  implemented  at  this  level.  The  session  layer  establishes  connection 
between  machines  or  processes,  known  as  establishing  a virtual  circuit.  This  requires 
determining  the  address  of  the  other  machine  and  agreeing  on  a port  number  (numerical 
handle).  This  function  is  handled  by  the  network  server.  The  transport  layer  handles  most 
of  the  ‘grunt”  work.  It  is  responsible  for  delivery  of  data  and  possibly  routing  and  verifica- 
tion of  receipt.  This  layer  also  has  knowledge  of  allowable  packet  sizes  for  the  physical 
network,  and  will  segment  the  data,  if  necessary,  into  appropriate  sized  packets.  The 
receiving  end  is  responsible  for  reassembly  of  segmented  packets  which  includes  handling 
packets  out  of  sequence  and  lost  packets.  The  transport  layer  is  also  responsible  for  rout- 
ing packets  to  their  destination,  but  routing  is  not  necessary  for  a local  area  network 
(LAN)  since  all  machines  will  be  directly  accessible.  The  network  layer  will  package  the 
IP  data  for  transmission  across  the  physical  network.  For  ethemet  its  main  function  is  in 
performing  the  IP  to  ethemet  address  mapping.  The  data  link  provides  error  detection  and 
possible  enror  correction,  and  the  physical  layer  is  the  actual  hardware  standard  used. 
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The  low-level  hardware  aspect  of  Ethernet  communications  is  based  on  carrier- 
sense/multiple-access  with  collision  detection  (CSMA/CD).  This  allows  multiple  comput 
ers  to  be  directly  connected  to  the  same  physical  cable  and  have  direct  access  to  each 
other.  All  computers  monitor  the  line  simultaneously  (multiple  access).  Before  messages 
are  sent  out,  the  network  is  checked  to  see  if  another  computer  is  using  the  cable  (carrier 
sense).  If  the  line  is  idle,  the  message  is  sent.  If  two  or  more  computers  attempt  simulta- 
neous access  of  the  line,  the  collision  detection  system  will  inform  the  computer  to  abort 
the  message  and  wait  a random  period  of  time  before  access  is  re-attempted.  The  hardware 
(physical  layer)  is  defined  by  the  IEEE  802.3  standard.  The  lowest  level  software  (data 
link  layer)  is  defined  in  the  IEEE  802.2  standard.  Ethernet  is  a broadband  network  with  a 
through-put  of  10  Mbits/sec. 

Network  Software 

TCP/IP  is  a communications  standard  that  encompasses  the  session,  transport,  and 
network  layers.  At  the  session  layer  coordination  between  processes  is  established  for 
TCP  transfers.  This  involves  determining  the  machine  address  and  establishing  a unique 
port  number.  At  the  transport  layer  TCP  data  streams  are  segmented  into  standard  Ethernet 
packets.  The  protocol  ensures  that  lost  packets  are  re-transmitted  and  that  the  packets  are 
re-assembled  in  the  correct  order.  UDP  packets  are  formatted  into  a single  Internet  data- 
gram. Their  transmission  is  not  verified. 

UDP  protocol 

The  UDP  protocol  provides  a procedure  for  application  programs  to  send  messages 
to  other  programs  with  a minimal  of  protocol  mechanism.  Delivery  of  datagrams  and  pre- 
vention of  duplicate  datagrams  is  not  guaranteed.  However,  the  Ethernet  LAN  is  a reliable 
transport,  and  the  use  of  UDP  is  adequate  as  well  as  efficient. 

Figure  4-9  shows  the  UDP  packet  format.  An  eight  byte  header  is  attached  to  the 
data.  The  header  identifies  a source  and  destination  port.  The  port  number  is  an  identifier 
for  a specific  process  on  a machine.  The  receiving  machine  can  use  this  number  to  decide 
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Figure  4-9.  User  datagram  header  format. 


how  to  handle  the  datagram.  The  source  port  number  is  not  required  for  transmission.  It 
could  be  used  as  a means  of  generating  a reply  message.  The  length  is  the  length  of  the 
data,  the  UDP  header  (8  bytes),  and  the  pseudo  header  (described  below). 

The  pseudo  header  (figure  4-10)  is  conceptually  prefixed  to  the  UDP  header.  It  will 
be  used  at  a lower  network  layer  to  form  the  IP  header.  However,  this  information  is  used 

m computing  the  length  and  check  sum  for  the  UDP  header.  The  UDP  datagram  must  fit 
within  one  IP  datagram. 

IP  protocol 

The  IP  datagram  [63]  is  the  low  level  transport  of  the  TCP/IP  protocol.  It  is  the  last 
layer  before  hardware  dependent  parameters  must  be  considered.  The  IP  header  (figure  4- 
1 1 ) is  variable  in  length  but  must  be  a four  byte  multiple.  The  four  bit  version  number  is  4. 
The  four  bit  Internet  Header  Length  (IHL)  is  the  length  of  the  header  in  32  bit  words.  It 
must  be  a minimum  of  5 (20  bytes).  The  Type  of  Service  flags  provide  abstract  parameters 
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Version  IHL  Type  of  Service 

Total  Length 

Identification  Flags 

Fragment  Offset 

Time  to  Live  Protocol 

Header  Checksum 

Source  Address 

Destination  Address 

Options  Padding 


Figure  4-11.  Internet  datagram  header. 

to  indicate  a quality  preference.  The  actual  interpretation  is  network  dependent,  and  will 
not  be  used  for  the  present  system.  Total  Length  is  the  length  of  the  total  IP  datagram, 
including  the  header  and  the  data.  It  has  a maximum  length  of  65,535  bytes,  but  576  bytes 
is  more  typical  of  the  maximum  size.  If  the  size  is  larger  that  1492  bytes  (the  maximum 
transmission  unit  (MTU)  of  the  Ethernet),  then  the  datagram  will  need  to  be  fragmented 
across  the  Ethernet  LAN.  A 16  bit  identifier  is  used  to  aid  in  re-assembly  of  datagrams 
when  fragmentation  was  necessary.  Three  bits  are  provided  for  flags  used  to  decide 
whether  fragmentation  is  allowed  or  if  the  datagram  was  fragmented.  If  fragmentation 
occurred,  then  the  13  bit  fragment  offset  is  used  to  place  an  incoming  fragment  correctly 
in  the  original  datagram.  The  Time  to  Live  value  is  used  mainly  for  WAN’s.  When  a data- 
gram is  created  it  is  given  a maximum  time  to  exist.  Whenever  the  datagram  is  processed, 
its  value  will  be  decreased.  When  the  value  reaches  zero,  the  datagram  is  destroyed.  This 
prevents  disorientated  datagrams  from  wandering  aimlessly  across  the  Internet  for  all  eter- 
nity. The  protocol  is  taken  from  the  one  specified  in  the  UDP  pseudo  header.  A check  sum 
is  maintained  on  the  header  since  it  may  change  at  intermediate  nodes  (e.g.  time  to  live). 
The  check  sum  is  computed  by  taking  the  one’s  complement  of  the  one’s  complement 
sum.  This  is  a simple  algorithm,  but  has  proven  to  be  adequate.  The  source  and  destination 
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DSAP=K1 

SSAP=K1 

Control 

LLC  Header 

Protocol  ID  or  Organization  Code 

EtherType 

SNAP  Header 

Figure  4-12.  IEEE  802.2  headers. 

addresses  are  the  four  byte  Internet  addresses  taken  from  the  UDP  pseudo  header.  Options 
can  be  used  to  place  additional  information  to  aid  in  interpreting  and  reacting  to  IP  data- 
grams. For  this  application,  the  use  of  options  is  not  anticipated. 

The  total  header  overhead  is  20  (IP  header)  + 8 (UDP  header)  = 28  bytes.  This 
leaves  1492  (Ethernet  MTU)  - 28  = 1464  bytes  for  transmitting  data  without  fragmenting 
the  IP  datagram. 

Ethernet  protocol 

Figure  4-12  shows  the  header  specified  by  the  IEEE  802.2  protocol.  The  Logic  Link 
Layer  (LLC)  and  the  Sub  Network  Access  Protocol  (SNAP)  could  be  used  to  classify 
packets  according  to  intended  recipient  groups,  particular  Ethernet  standard,  and  protocol. 
For  the  Internet  Protocol,  the  Destination  Service  Access  Point  (DSAP)  and  the  Source 
Service  Access  Point  (SSAP)  are  each  set  to  170,  which  designates  the  use  of  the  SNAP 
header.  The  control  number  is  3,  standing  for  unnumbered  information.  The  Protocol  ID  is 
set  to  0.  The  EtherType  will  be  one  of  two  values.  A value  of  2048  represents  IP  data- 
grams, and  2054  represents  an  ARP  request.  The  LLC  header  is  three  bytes,  and  the  SNAP 
header  is  five  bytes  (3  for  Protocol  and  2 of  EtherType)  for  a total  of  8 bytes. 

The  IEEE  802.3  protocol  defines  the  following  format  for  transmitting  packets  (fig- 
ure 4-13).  Each  Ethernet  interface  is  given  a unique  6 byte  address  by  the  manufacturer. 
The  IEEE  802.3  header  contains  the  6 byte  address  for  the  destination  and  source  of  the 
packet.  This  address  differs  from  the  4 byte  Internet  address  specified  at  the  higher  layers. 
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Destination  Address 

Source  Address 

Length 

Data 

Data ... 

Frame  Check  Sequence 

Figure  4-13.  IEEE  802.3  header. 

IEEE  802.3 

IEEE  802.2 

IP 

UDP 

Data 

IEEE  802.3  Check  Sum 

Figure  4-15.  Structure  of  complete  network  packet. 


The  translation  of  Internet  addresses  to  Ethernet  addresses  is  know  as  the  Address  Resolu- 
tion Protocol  (ARP)  [64,65].  Each  computer  maintains  a table  of  Internet  to  Ethernet  map- 
pings. When  an  unknown  address  is  encountered,  a broadcast  message  is  sent  onto  the 
Ethernet  (broadcast  messages  are  received  by  all  machines  on  the  LAN).  The  message 
contains  the  unknown  Internet  address,  and  if  a machine  that  owns  that  address  receives 
this  message,  a reply  is  sent  to  provide  the  correct  Ethernet  address.  Two  bytes  are  pro- 
vided for  the  length  of  the  packet.  A four  byte  check  sum  is  placed  on  the  end  of  the 
packet.  This  brings  the  total  to  18  bytes  for  the  IEEE  802.3  header. 

Preceding  the  transmission  of  the  Ethernet  datagram,  a 7 byte  preamble  followed  by 
the  byte  value  1010101  IB  are  sent  so  that  the  receiving  machine’s  Ethernet  card  can  syn- 
chronized with  the  incoming  datagram. 

Figure  4-14  shows  the  software  layers  in  relation  to  the  ISO  OSI  model.  The  com- 
plete packet  format  is  shown  in  figure  4-15.  The  total  header  size  is  18  (IEEE  802.3)  + 8 
(IEEE  802.2)  + 20  (IP)  + 8 (UDP)  = 54  bytes.  The  allowed  packet  sizes  for  the  Ethernet 
range  for  64  to  1518  bytes.  This  provides  for  minimum  data  size  of  10  bytes,  and  a 
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Figure  4-14.  Relationship  of  ISO  OSI  model  to  network  protocols. 


maximum  data  size  ot  1464  bytes.  Larger  or  smaller  datagrams  must  be  fragmented  or 
padded  to  fit  within  this  range. 

TCP/IP  Software 

UNIX  based  workstations  come  standard  with  the  Ethernet  interface  and  the  soft- 
ware tools  to  allow  entry  at  the  various  ISO  OSI  levels.  On  the  UNIX  side  a single  func- 
tion call  will  send  a message  or  wait  to  receive  a message  from  the  network.  All  action 
between  the  various  layers  is  invisible. 

PC  TCP/IP 

TCP/IP  is  not  a program,  it  is  a set  of  protocols  which  have  been  implemented  on 
many  machines.  All  machines  running  an  implementation  of  TCP/IP  and  connected  to  the 
Internet  are  capable  of  communicating  with  each  other.  The  PC  implementation  of  TCP/IP 
is  a package  developed  by  Erick  Engelke  at  Waterloo,  Ontario,  called  WATTCP.  This 
package  provides  the  source  code  for  TCP/IP,  and  was  integrated  into  the  PC’s  supervisory 
software.  This  software  is  available  from  the  public  ftp  server  Sunee.uwaterloo.ca. 

There  are  numerous  manufacturers  of  ethemet  cards  for  the  PC,  and  each  card  has  a 
different  program  interface.  In  an  effort  to  make  all  cards  available  under  a uniform 
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interface,  a software  driver  is  installed  that  knows  the  interface  to  the  card  and  provides  a 
uniform  interface  to  the  application.  This  standard  was  defined  by  FTP  Software,  Inc.,  and 
made  publicly  available.  These  drivers  are  being  created  by  both  individuals  and  manufac- 
turers, and  are  freely  available.  The  central  distribution  point  is  Crynwr  Software,  Russ 
Nelson,  nelson@crynwr.com. 


CHAPTER  5 
CNC  INTERFACE 

Interface  Guidelines 

An  integral  part  of  this  supervision  system  is  the  ability  to  command  access  to  the 
Flexmate  CNC.  To  make  this  possible,  the  structure  of  the  CNC  must  be  studied.  This 
chapter  discusses  the  software  modifications  to  the  CNC  that  provide  the  interface  capabil- 
ity. A set  of  software  layers  will  be  built  to  provide  for  reliable  communication  and  a con- 
venient development  environment.  The  result  will  be  a CNC  to  ethemet  interface  that  will 
be  generally  invisible  to  the  application  programmer.  When  it  is  necessary  for  the  applica- 
tion programmer  to  modify  the  interface  function  to  provide  a new  CNC  control  option, 
the  software  layers  will  provide  high  level  tools  that  alleviate  the  need  for  the  programmer 
to  be  concerned  with  low  level  I/O  details. 

The  details  of  the  CNC  were  obtained  with  the  cooperation  of  the  manufacturer  of 
the  Flexmate  CNC,  Automation  Intelligence,  and  the  solution  for  the  interface  was  pro- 
duced in  conjunction  with  Lindsey  Wells  [66], 

Flexmate  CNC 

Figure  5-1  shows  the  architecture  of  the  Flexmate  controller.  It  consists  of  two  sepa- 
rate computers.  An  IBM  industrial  PC  is  used  as  a front  end  providing  a graphical  user 
interface  and  hard  disk  storage  for  parts  programs.  The  parts  program  specifies  a sequence 
of  steps  for  the  machine  tool  to  perform. 

When  the  user  selects  a parts  program,  the  PC  loads  the  program  from  disk  and  for- 
wards it  to  the  second  computer  (the  MCP).  This  is  where  the  actual  computation  is  per- 
formed. The  MCP  interprets  the  CNC  program  and  other  user  directed  commands  from 
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the  console,  and  provides  the  correct  control  signals  to  the  machine  tool,  which  is  a Series 
20  Omnimil. 

Figure  5-2  shows  a simplified  connection  of  the  Flexmate  CNC  with  the  Omnimill. 
The  Flexmate  has  axis  control  boards  that  update  positional  information  to  each  of  three 
axis  of  the  Omnimil.  The  axis  boards  are  updated  every  10  msec.  There  are  also  A/D  and 
D / A ports  to  adjust  and  monitor  the  analog  control  lines  of  the  Omnimil  for  velocity,  spin- 
dle speed,  etc. 

The  two  cards  that  will  be  used  for  our  system  are  the  IOQ  (I/O  converter  driver)  and 
FIB  (fast  interrupt  board).  The  IOQ  provides  64  bits  of  I/O  (four  16  bit  ports).  The  FIB 
board  provides  an  external  interrupt  capability  for  the  MCP,  or  can  be  used  for  8 bit  paral- 
lel input. 
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Figure  5-3.  Time  scheduling  of  the  MCP  processes. 

Software  Structure  of  Flexmate  MCP 

The  MCP  runs  in  a task  switching  environment  which  allows  the  computer  to  switch 
between  a maximum  of  32  programs.  Of  these,  two  programs  are  of  interest  to  the  devel- 
oper. These  programs  are  called  OEM_SYNC  and  OEM_MAIN.  A 100  Hz  timer  is  used 
to  execute  OEM_SYNC  every  10ms.  OEM_SYNC  must  begin  and  finish  within  the  10ms 
time  frame.  If  the  MCP  detects  that  this  is  not  met,  then  the  MCP  will  alert  the  user  of  the 
error  and  halt.  0EM_MA1N  runs  after  OEM_SYNC  and  is  suspended  at  the  end  of  the 
10ms  time  frame.  However,  when  OEM_MAIN  is  resumed  in  the  next  time  frame,  it  will 
continue  from  the  point  at  which  it  was  suspended.  That  is,  OEM_MAIN  does  not  need  to 
finish  during  its  time  allotment,  and  consequently  runs  its  code  within  an  infinite  loop. 
Figure  5-3  shows  a hypothetical  timing  diagram  of  this  operation.  The  time  scale  is 
marked  off  in  milli-seconds.  The  S marks  the  time  that  OEM_SYNC  begins  executing. 
The  M marks  the  time  that  OEM_MAIN  begins  executing.  Starting  at  0,  OEM_SYNC 
runs  for  4 ms  and  stops.  Them  OEM_MAIN  begins  at  4 ms  and  continues  for  6 ms,  at 
which  time  OEM_MAIN  is  suspended  and  OEM_SYNC  is  started.  In  this  case  OEM_- 
SYNC  runs  for  3 ms  and  stops.  OEM_MAIN  is  then  continues  from  where  it  was  previ- 
ously suspended.  It  runs  for  7 ms,  at  which  time  it  is  suspended  and  OEM_SYNC  is 
started.  For  this  instance  it  runs  for  5 ms  and  stops.  OEM_MAIN  again  continues  and  runs 
for  5 ms.  The  diagram  shows  that  OEM_SYNC  is  executed  every  10  ms.  The  time  that  is 
runs  can  vary,  but  it  must  complete  in  less  than  10  ms.  OEM_MAIN  will  then  run  in  the 
time  remaining  in  the  10  ms  interval.  At  the  end  of  the  10  ms  it  is  suspended,  and  then 
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continued  in  the  next  10  ms  interval  after  OEM_SYNC  again  tuns  and  stops.  Also  note 
.ha,  the  two  programs,  OEM.SYNC  and  OEM.MAIN  appear  to  consume  all  available 
time  and  leave  no  time  for  the  MCP  to  run  any  other  programs.  The  truth  is  tha,  the  MCP 
is  constantly  switching  tasks  so  that  during  the  time  that  OEM.SYNC  and  OEM.MAIN 
are  running,  the  CPU  time  is  being  shared  with  other  programs. 

OEMJi  YNC  is  intended  to  run  code  that  needs  to  be  executed  a,  the  tegular  interval 
of  10  ms.  However,  the  execution  time  of  the  program  must  remain  short,  and  the  memory 
available  for  OEM_SYNC  code  is  small  (around  2 Kilobytes,.  The  executton  time  for 
OEM.MAIN  can  be  as  long  as  desired,  and  the  memory  available  for  program  memory  is 
large  (around  64  Kilobytes).  OEMJSYNC  and  OEM.MAIN  do  not  contain  the  code  for 
the  basic  machine  functions.  The  program  for  interpreting  the  machinist’s  part  program 
and  the  code  for  updating  the  axis  positions  are  external  and  proprietary. 

MCP  Built-in  Control  Functions 

The  MCP  programming  environment  provides  a library  of  functions  known  as  win- 
dow functions.  These  functions  provide  access  to  common  machining  functions.  It  will  be 
by  the  use  of  these  functions  that  the  developer  will  modify  the  actions  of  the  CMC 

PC  to  MCP  Interface 

A PC  equipped  with  a parallel  card  (32  bits  I/O)  will  be  used  to  mterconnect  through 
the  two  aforementioned  MCP  cards.  Fig™  5-4  shows  the  proposed  system.  The  PC  will 
communicate  directly  with  the  MCP  through  a digital  I/O  pott  to  the  digital  I/O  port  of  the 
MCP.  A connection  into  the  FIB  card  of  the  MCP  will  be  used  to  interrupt  the  MCP  to 
handle  the  I/O  transfers.  The  design  of  the  remaining  hardware  interface  and  software  pro- 
tocol depend  on  the  following  requirements  of  the  control  project.  Afterwards,  the  detailed 
hardware  interconnection  will  be  presented. 
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Communications  Model 

Before  describing  the  hardware  interface,  the  software  requirements  need  to  be 
addressed.  The  interface  PC  will  need  to  send  information  to  the  MCP  that  instructs  the 
MCP  to  perform  some  function.  After  the  MCP  completes  the  task,  it  will  return  informa- 
tion back  to  the  interface  PC  to  report  on  the  status  of  the  request.  This  type  of  communi- 
cation follows  the  structure  of  a procedure  call  in  that  the  PC  calls  a function  on  the  MCP 
and  then  awaits  the  results.  The  intention  is  to  create  a software  layer  that  will  provide  a 
procedure  call  interface.  This  layer  needs  to  format  data  into  a form  that  is  presentable  to 
the  MCP,  and  handle  the  I/O  transfers.  The  actual  means  of  data  transfer  and  the  fact  that 

the  function  takes  place  on  a remote  machine  will  not  be  visible  to  the  application  pro- 
grammer. 

Remote  Procedure  Call  Structure 

A remote  procedure  call  (RPC)  [68]  will  be  created  to  hide  the  low-level  I/O  from 
the  user.  The  MCP  will  be  the  RPC  server.  It  will  serve  requests  made  by  the  interface 
computer.  The  interface  computer  will  be  a client,  and  make  request  of  the  MCP. 
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command 

tr_data_type 

tr_data ... 

rc_data_type 

Figure  5-5.  RPC  data  packet  structure. 

The  RPC  software  is  a layer  that  exists  between  the  user  and  the  actual  I/O  hard- 
ware. This  module  will  receive  request  from  the  user  program  and  handle  all  low-level  V 
O.  This  will  not  only  make  the  PC  to  MCP  communications  easier,  but  also  prevent  the 
user  from  improperly  controlling  the  I/O  which  could  cause  the  Omnimill  to  take  detri- 
mental actions  (such  as  halting). 

The  RPC  interface  is  similar  to  a normal  procedure  call  containing  five  arguments: 
command,  tr_data_type,  tr_data,  rcv_data_type,  and  rcv_data.  The  command  parameter 
identifies  a function  that  should  be  performed  by  the  server.  The  tr_data_type  parameter 
identifies  the  form  of  the  data  (integer,  float,  etc.).  The  tr.data  parameter  is  the  data  to  be 
transmitted.  The  rc_data_type  parameter  identifies  the  form  of  the  returned  data.  The 
rc_data  parameter  is  the  storage  location  for  the  returned  data  The  command, 
tr_data_type,  and  rc_data_type  are  each  two  bytes.  The  length  of  the  data  varies.  The  vari- 
able tr_data_type  will  identify  the  length  and  format  of  tr_data.  The  variable  rc_data_type 

will  describe  the  format  for  the  data  to  be  returned.  The  resulting  message  format  is  shown 
in  figure  5-5. 

External  Data  Representation 

The  reason  for  specifying  a data  type  as  a parameter  for  an  RPC  call  is  to  allow  mul- 
tiple formats  to  be  specified.  The  formalism  for  an  external  data  representation  [45]  pro- 
vides a software  layer  to  format  the  data  into  a common  format.  Given  the  data  type 
identifier,  the  PC  and  the  MCP  will  know  the  proper  procedure  for  the  I/O  transfer. 
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1111110000000000 

5432109876543210 

SDDDDDDDDDDDDDDE 


S = sign  bit,  D = data  bit 
Figure  5-6.  Short  integer  format. 


33222222222211111111110000000000 

10987654321098765432109876543210 


SDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 


Figure  5-7.  Long  integer  format. 


Two  data  types  are  used  by  the  Flexmate:  long  integers  (4  bytes)  and  short  integers 
(2  bytes).  For  the  user  functions  provided  by  MCP,  one  or  more  parameters  are  used  for 
input,  and  one  are  none  are  returned.  The  data  types  that  need  to  be  recognized  by  the  RPC 
layer  are  short  integer  (short),  long  integer  (long),  void,  and  arrays  of  short  or  long  inte- 
gers. External  data  representation  provides  for  a uniform  format,  and  the  data  type  identi- 
fier informs  the  low  level  I/O  routine  how  to  handle  the  transfer. 


RPC  Format 

Several  data  formats  are  defined  for  use  in  communication  through  the  RPC  proto- 
col. The  details  of  allowable  data  formats  are  defined  in  the  following  sections. 

Short  integer  format 

The  format  type  for  two  byte  integers  is  defined  as  RPC_SHORT.  The  format  is 
shown  in  figure  5-6.  Note  that  the  bytes  are  not  swapped.  The  most  significant  byte  is  first. 
Long  integer  format 

The  format  for  four  byte  integers  is  defined  as  RPC_LONG.  The  format  is  shown  in 
figure  5-7.  Again,  bytes  are  ordered  from  most  significant  to  least  significant. 

Short  integer  array  format 

The  format  for  arrays  of  two  byte  integers  is  defined  as  RPC_SHORT_ARRAY.  The 
format  for  an  array  of  length  N is  shown  in  figure  5-8.  The  variable  Length  will  equal  N, 
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Length 

Element  0 

Element  1 

... 

Element  N-l 

Figure  5-8.  Array  format. 


the  length  of  the  data.  The  variable  type  tor  length  will  be  the  same  as  the  data,  will  allows 
a maximum  array  length  65535.  The  length  of  the  resulting  package  will  be  (N+l)*2  bytes 
long. 

Long  integer  array  formnf 

The  format  for  arrays  of  four  byte  integers  is  defined  as  RPC_LONG_ARRAY.  The 
format  for  an  array  of  length  N is  shown  in  figure  5-8.  The  variable  Length  will  equal  N, 
the  length  of  the  data.  The  variable  type  for  the  length  will  be  the  same  as  the  data  type, 
and  will  allow  a maximum  length  of  4,294,967,295  elements.  The  length  of  the  resulting 
package  will  be  (N+l)*4  bytes  long. 

Although  the  array  specifications  allow  large  sizes,  the  storage  area  available  on  the 
Flexmate  will  limit  the  size  to  a much  smaller  size.  Anyway,  an  examination  of  functions 
used  on  the  Flexmate  showed  a maximum  parameter  size  of  three  integers.  However,  the 

maximum  packet  size  will  be  determined,  and  the  RPC  layer  will  check  for  packets  over 
the  allowed  limit. 


RPC  Example 

To  clarify  the  use  of  the  RPC  function  call  and  the  use  of  the  data_type  descriptors, 
the  following  examples  are  provided. 

If  a user  wanted  to  determine  the  spindle  velocity,  the  following  call  would  be  made. 
The  routine  would  not  require  any  input,  and  would  return  a short  integer  result.  Also, 
assume  that  the  constant  MCP_SPINDLE_SPEED  represents  the  command  number  for 
this  function,  and  the  variable  velocity  is  a pointer  to  short  integer. 

mpc_call(MCP_SPINDLE_SPEED,RPC_  VOID, 0,RPC_SHORT, velocity); 
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As  a more  complicated  example,  consider  a function  that  takes  three  short  integers 
as  input  and  returns  a long  integer.  First  the  three  integers  need  to  be  put  into  an  array, 
short  int  out_data[4]; 

The  length  of  four  was  used  because  the  array  contains  the  number  of  elements  in 
the  first  location,  followed  by  the  three  array  parameters.  The  array  is  packed  as  follows. 

out_data[0]  = 3;  /*  the  length  of  the  data  */ 
out_data[l]  = first_parameter; 
out_data[2]  = second_parameter; 
out_data[3]  = third_parameter; 

The  command  number  for  the  function  will  be  MCP.EXAMPLE,  and  the  location 

for  the  return  value  will  be  in_data  (a  pointer  to  a long  integer).  Below  is  the  resulting 
RPC  call. 

mcp_call(MCP_EXAMPLE,RPC_SHORT_ARRAY 
out_data,R  PC_LONG,in_data) ; 

The  function  mcp_call()  will  also  return  an  integer  to  report  on  any  errors  that 
occurred  in  the  transaction.  Errors  would  include  invalid  command  number,  invalid 
data_type  for  transmit  or  receive,  unable  to  contact  MCP,  and  data  packet  too  large. 

RPC  Server  Software 

The  Flexmate  will  be  responsible  for  unpacking  the  data  into  the  correct  format, 
calling  the  appropriate  routine  based  on  command  number,  packing  the  resulting  data  for 

the  return  transfer,  and  the  low-levei  I/O.  The  low-level  I/O  will  be  described  below  in  the 
hardware  section. 

A memory  buffer  will  be  allocated  to  hold  incoming  data.  Data  will  be  sequentially 
placed  into  this  buffer  as  it  is  received  from  the  interface  PC.  If  any  formatting  of  the  data 
needs  to  be  done,  it  will  be  done  at  this  time.  The  command  number  will  be  evaluated 
using  a switch  statement,  which  will  branch  the  program  to  the  appropriate  service  rou- 
tine. The  coding  of  this  would  have  the  following  structure. 
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switch(command_number)  { 

case  COMMAND_ONE:  do_function_one(); 

break; 

case  COMMAND_LAST:  do_function_last(); 

break; 

} 

In  the  above  program  structure,  the  user  can  add  a new  function  to  the  Flexmate  by 
adding  another  case  inside  of  the  switch  statement.  Code  preceding  the  switch  statement  is 
responsible  for  reading  the  data  from  the  interface  PC  and  code  after  the  switch  statement 
is  responsible  for  sending  the  code  back  to  the  interface  PC.  The  user  only  needs  to  insert 
a new  case  inside  of  the  switch  statement  and  re-compile  the  program  to  add  a new  func- 
tion to  the  Flexmate.  By  not  letting  the  user  touch  the  actual  I/O  transfers,  the  probability 
of  maintaining  a working  program  is  greatly  increased.  Also,  adding  user  applications  will 
be  simplified. 


Hardware  Connection 

The  interface  PC  and  the  Flexmate  MCP  are  both  configured  with  a digital  I/O  card. 
The  interface  PC  has  the  capability  of  32  bits  of  I/O  (Data  Translation  DT2817)  and  the 
MCP  has  64  bits  of  I/O  (Flexmate  IOQ  board).  With  the  PC  having  less  I/O  lines,  the 
interface  was  designed  to  fit  its  capabilities.  Both  the  PC  and  the  MCP  have  their  I/O 
divided  into  four  separate  ports,  each  can  be  configured  as  all  output  or  all  input  on  a port- 
wise  bases. 

Figure  5-9  shows  the  hardware  configuration  [66,  p.  61].  An  8 bit  connection  was 
hooked  from  the  PC  to  the  MCP,  and  an  8 bit  connection  was  run  from  the  MCP  to  the  PC. 
This  provides  a means  to  transfer  of  data  from  the  PC  to  the  MCP  (MCP  read)  and  data 
from  the  MCP  to  the  PC  (MCP  write)  in  8 bit  chunks.  To  distinguish  between  read  and 
write  operations,  the  MCP  has  a control  line  for  the  read  (R)  and  a control  line  for  write 
(W)  operations.  As  seen  in  the  above  examples,  a read  or  write  operation  can  involve  more 
than  one  byte  of  data,  so  the  PC  was  given  an  acknowledge  (ACK)  control  line  to 
acknowledge  each  byte  of  transfer.  The  MCP  was  given  a Transfer  Ready  (TR)  line  to 
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indicate  transfer  ready  status.  The  MCP  has  an  external  interrupt  capability  through  its 
Fast  Interrupt  Board  (FIB).  A control  line  is  connected  to  from  the  PC  to  the  FIB  input  to 
give  the  PC  interrupt  capability  on  the  MCP.  This  interrupt  will  be  used  by  the  PC  to  ini- 
tiate the  data  packet  transfer. 


90 


R 


w 

TR 

Data 

ACK 

first  word 
transfer 

Figure  5-10.  MC 

:Pn 

second  word 
transfer 

;ad  timing  diag 

rarr 

L 

Data  Translation  Layer 

To  better  visualize  the  transfer  operation,  consider  a general  RPC  data  packet. 


command 

output_data_type 

output_data 

input_data_type 

The  command,  input_data_type,  and  output_data_type  are  each  two  bytes.  The 
length  of  the  output_data  varies  in  length  according  to  the  operation.  Its  length  is  given  by 
its  data  type  identifier.  When  the  user  makes  a RPC  function  call,  the  RPC  layer  forms  this 
data  packet,  formatting  the  output  data  according  to  the  XDR  routines.  The  data  packet  is 
then  forwarded  to  data  transfer  layer.  The  basic  operations  of  the  data  translation  layer  are 
coordinating  with  multi  byte  MCP  writes,  and  multi  byte  MCP  reads. 

Multi-Bvte  Read 

In  this  case  the  MCP  is  reading  a packet  of  bytes  from  the  PC.  Figure  5-10  provides 
the  timing  diagram  for  operation.  The  MCP  starts  the  cycle  by  setting  the  R line  high  and 
the  W line  low.  It  then  sets  the  TR  line  high  to  signal  that  it  is  ready  to  receive  the  first 
byte.  The  PC  then  sets  the  data  lines  with  the  value  of  the  first  byte  and  sets  the  ACK  line 
to  acknowledge  that  the  data  is  ready.  The  MCP  reads  the  data  and  clears  the  TR  line  to 
acknowledge  that  the  data  has  been  read.  The  PC  then  clears  the  ACK  line  to  signal  the 
end  of  the  first  byte  transfer.  With  the  ACK  line  clear,  the  MCP  can  proceed  with  the 
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Figure  5-11.  MCP  write  timing  diagram. 


second  byte  transfer  by  setting  the  TR  line.  The  PC  sets  the  data  lines  with  the  second  byte 
and  sets  the  ACK  line  to  signal  that  the  data  is  ready.  The  MCP  reads  the  data  and  clears 
the  TR  line  to  signal  that  the  data  has  been  read.  Then  the  PC  clears  the  ACK  line  to  signal 

the  end  of  the  byte  transfer.  Finally,  the  MCP  clears  the  R line  to  signal  the  end  of  the 
multi  byte  read. 


Multi-Bvte  Write 

The  multi  byte  write  operation  proceeds  similar  to  the  write  operation.  Figure  5-11 
shows  the  timing  diagram  for  a two  byte  MCP  write  operation,  that  is,  receiving  a two  byte 
data  packet  from  the  MCP.  The  operation  is  begun  by  setting  the  W line  high  to  indicate  a 
write  operation.  The  data  lines  are  set  to  the  value  of  the  first  byte.  The  TR  line  is  set  to  tell 
the  PC  that  the  data  lines  are  valid.  The  PC  reads  the  data  and  sets  the  ACK  line  to  inform 
that  MCP  that  the  data  has  been  read.  The  MCP  clears  the  TR  line  to  acknowledge  the 
acknowledgment.  The  PC  clears  the  ACK  line  and  the  MCP  releases  the  data  lines  (or,  the 
data  is  no  longer  valid).  To  transfer  the  second  byte  (or  any  subsequent  byte),  the  W line 
remains  high,  the  next  byte  is  placed  on  the  data  lines,  and  the  TR  line  is  set.  The  transfer 

of  the  byte  then  proceeds  as  above.  When  the  complete  byte  sequence  is  written,  the  W 
line  is  cleared. 
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Low-Level  I/O  Details 

With  the  formation  of  the  RFC  packet  given  and  the  two  basic  transfer  modes 
described,  the  function  of  the  data  transfer  layer  can  be  described.  The  data  transfer  layer 
will  receive  the  RPC  packet  from  the  RPC  layer.  The  FIB  interrupt  line  is  set  high  to  force 
the  MCP  into  a service  routine.  The  MCP  will  initiate  the  multi  byte  read  routine.  The  first 
two  bytes  sent  to  the  MCP  will  be  the  command  word.  The  MCP  will  store  this  word  in 
temporary  storage.  The  next  two  bytes  sent  will  be  the  output_data  type.  This  value  will  be 
parsed  by  the  MCP  and  the  PC  to  decide  how  to  handle  the  data  transfer.  After  parsing  this 
value  the  MCP  and  the  PC  will  know  if  the  data  is  a long  or  short  integer,  or  if  the  data  is 
an  array  of  long  or  short  integers.  If  the  data  type  is  for  a short  integer,  then  a two  byte 
transfer  will  be  necessary.  If  the  data  type  is  for  a long  integer,  then  a four  byte  transfer 
will  be  necessary.  If  the  data  type  is  for  an  array,  then  the  first  transfer  will  be  for  the  size 
of  the  array.  That  data  transfer  will  be  two  or  four  bytes  depending  on  data  type  for  the 
array.  With  then  length  of  the  array  known,  then  the  appropriate  number  of  two  or  four 
byte  transfers  can  be  performed.  After  the  transfer  of  the  output  data,  then  one  final  two 
byte  transfer  is  necessary  for  the  MCP  to  get  the  input_data  type.  All  of  this  data  is  stored 
in  temporary  storage  in  the  MCP.  The  MCP  will  parse  the  command  value  to  determine 
the  appropriate  handling  routine.  The  handling  routine  will  check  the  output_data_type 
and  the  input_data_type  to  verify  that  the  correct  data  format  was  sent  and  the  correct 
return  data  format  is  expected.  If  the  data  formats  are  correct,  then  the  handling  routine 
will  perform  its  designated  function  and  place  the  return  data  in  temporary  storage.  The 
PC  will,  of  course,  be  waiting  for  the  return  transfer. 

By  parsing  the  input_data_type,  the  MCP  and  the  PC  will  know  the  proper  proce- 
dure for  the  return  transfer.  The  MCP  will  initiate  the  multi  byte  write  routine,  and  transfer 
the  data  back  to  the  PC.  The  PC  will  than  forward  the  data  back  to  the  RPC  layer  which 
will  store  the  data  at  the  location  specified  by  the  user  function. 


CHAPTER  6 

SUPERVISION  SYSTEM 


System  Specification 

The  previous  chapters  have  described  models  at  various  levels  of  control.  The  over- 
all goal  of  those  discussions  were  directed  toward  control  of  a machine  tool  by  means  of 
integrating  a system  of  computers  that  implement  elements  of  monitoring  and  supervision. 
This  chapter  presents  an  application  that  includes  a CNC  interface  and  tool  breakage  mon- 
itoring. This  application  will  be  used  to  discuss  the  operator  interface  and  the  application 
programmer’s  interface  to  the  system. 

Operator  Interface. 

Figure  6-1  presents  the  user  interface  to  the  supervision  system.  This  display  con- 
sists  of  several  display  objects  that  can  be  manipulated  by  the  user.  A typical  form  of  a dis- 
play object  is  the  data  display  object.  In  this  figure  there  are  two  data  display  views.  The 
data  within  these  views  is  generated  by  means  of  a data-server  to  display-server  connec- 
tion (described  in  chapter  4).  This  is  the  display  server  that  converts  the  data  into  the  pre- 
sentation format  that  is  seen  in  the  figure.  Maintaining  a separation  between  the  data 
server  and  the  display  server  makes  it  feasible  to  alter  the  presentation  form  of  the  data. 

Also,  maintaining  a separation  of  views  between  display  servers  provides  for  unrelated 
presentation  forms. 

At  present  the  data  displays  are  limited  to  temporal,  scrolling  views.  However,  new 
forms  of  presentation  could  be  added  by  creating  new  display  servera  and  connecting  them 
to  a data  server.  As  an  example  for  the  need  of  disjoint  view  parameter  the  Displacement 
view  is  single  channel  with  a display  data  length  of  6000  points  and  an  amplitude  range  of 
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-32768  to  32767,  whereas  the  Data  Capture  view  contains  two  channels,  has  a display 
length  of  600  points  and  an  amplitude  range  of  -2048  to  2047. 

The  upper  view  shows  the  magnitude  of  the  mean  displacement.  This  is  a continu- 
ous data  stream  of  the  synchronous  class.  It  maintains  a record  of  the  magnitude  of  the 
average  force  value  during  the  cut.  The  lower  right  view  presents  a synchronous-capture 
class.  That  is,  it  is  not  a continuous  stream  but  provides  a snap  shot  of  the  data  on  demand 
under  both  operator  and  program  control. 

Attributes  of  the  data  views  can  be  altered  by  the  operator  on  the  fly.  They  can  be 
hidden,  resized,  and  repositioned.  Other  attributes  are  accessible  through  the  view  inspec- 
tor. A view  inspector  is  shown  in  the  lower  left  comer.  It  allows  adjustment  of  the  ampli- 
tude scale  and  the  horizontal  data  length. 

Principal  control  functions  are  concentrated  in  the  Control  window.  The  Data  Flow 

buttons  control  the  Displacement  view.  This  is  a continuous  data  stream,  however  it  can  be 

paused  and  resumed  by  selecting  pause  and  resume,  and  pressing  quit  will  terminate  the 
connection. 

A set  of  CNC  functions  were  designed  on  top  of  the  interface  described  in  chapter  5. 
Two  of  these  ftinctions  are  implemented  here.  The  first  one  is  feed  hold.  Executing  a feed 
hold  on  the  CNC  will  halt  and  prevent  feed  movement  on  the  machine  tool.  Selecting  the 

FH  °Pti°n  WiU  t0ggle  the  feed  hold  state  of  ^e  CNC.  Halting  the  feed  is  an  option  that  is 
executed  upon  detection  of  tool  breakage.  Although  the  feed  hold  option  meets  this 

requirement,  its  speed  of  response  is  slow.  Therefore,  a fast  stop  function  was  added  to  the 
CNC  that  will  halt  the  feed  in  about  10  ms.  This  option  can  be  manually  executed  by 
selecting/**'  stop.  The  continue  button  will  clear  the  fast  stop  and  allow  the  CNC  to  con- 
tinue. The  fast  stop  option  is  normally  executed  under  program  control. 

Data  Capture  methods  are  used  to  capture  raw  displacement  data  from  the  tool 
breakage  system.  The  tool  breakage  system  maintains  a buffer  of  the  last  8192  samples  of 
displacement  data.  These  data  can  be  collected  at  any  time  and  saved  for  later  inspection. 
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This  feature  can  also  be  initiated  under  program  control  so  that  when  tool  breakage  is 
detected,  the  data  can  be  captured  and  saved.  A more  important  use  would  be  to  capture 
tool  breakage  data  for  instances  where  tool  breakage  was  not  detected. 

The  system  is  used  by  launching  the  ToolMon  application  on  the  NeXT  workstation 
followed  by  executing  the  ToolMon  program  on  the  PC.  Once  the  machine  tool  is  acti- 
vated, pressing  the  resume  button  will  display  the  average  force  of  the  cut.  When  tool 
breakage  occurs,  the  system  will  automatically  execute  a fast  stop  followed  by  data  cap- 
ture. The  operator  can  then  save  this  data  and  inspect  it  with  the  off-line  analysis  tool.  This 
beneficial  tool  will  be  presented  in  the  following  chapter.  It  not  only  enables  rapid  devel- 
opment of  supervision  routines,  but  also  functions  as  a debugging  tool  in  conjunction  with 
the  supervision  system’s  data  capture  facility. 

Program  Interface 

The  program  interface  was  written  for  ease  of  use.  A description  of  details  will  be 
covered  by  presenting  examples  of  typical  usage.  This  will  include  initiating  a data  mes- 
sage from  a supervision  sub-system  to  the  master  and  adding  data  servers. 

Initiating  a Data  Message 

For  this  example  a data  stream  is  connected  from  a PC  with  a software  library  writ- 
ten in  the  C++  programing  language.  C++  is  an  object  oriented  program  language  that 
aided  the  development  of  an  object-based  messaging  interface.  The  output  class  named 
TCPOutput  is  used  to  implement  connections  across  TCP/IP  networks.  Its  command  syn- 
tax is  shown  in  figure  6-2.  These  functions  are  for  establishing  connections  and  transmit- 
ting data.  The  code  excerpt  in  figure  6-3  shows  an  implementation  of  the  TCP/IP 
procedures.  A new  instance  of  an  object  is  created  from  the  class  definition  for  TCPOut- 
put. The  connection  is  established  by  specifying  the  destination  address  and  a port  number 
for  the  remote  application.  The  raw  displacement  header  is  chosen  to  designate  that  the 
data  will  be  raw  displacement.  The  format  type  MT_16_BIT  specifies  that  each  data 
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int  lCPUutput::connect(char  ’address,  int  portNum); 
Establish  TCP  connection  with  a remote  computer, 
address:  Address  of  remote  system. 

portNum:  Remote  application  identifier. 

returns: 

0 Command  Succeeded. 

1 Could  not  locate  address. 

2 Remote  computer  refused  connection. 

3 Remote  computer  terminated  connection. 

4 No  response  from  remote  computer. 

5 Unspecified  failure. 


int  TCPOutput::sendData(mt_samp  *data,  int  len); 
Send  data  over  a previously  established  connection, 
data:  Memory  address  of  data, 

len:  Length,  in  bytes,  of  data. 

returns: 

-1  Local  buffer  is  full. 

0 Data  successfully  transferred. 

3 Remote  computer  terminated  connection. 

4 No  response  from  remote  computer. 

5 Unspecified  failure. 


Figure  6-2.  TCP  messaging  commands. 


class  1 CPUutput  *tcp(Jut;/*  variable  declaration  */ 

tcpOut  = new  TCPOutput;/*  instantiate  object  */ 
tcpOut->init();  /*  initialize  the  new  object  */ 

establish  the  connection  *1 

if  (tcpOut->connect("  1 28.227. 1 00. 1 06" ,DISP_PORT)  !=  SUCCESS)  { 
fprintf(stderr,  "Error:  main:tcpOut:connect\n"); 
exit(-l); 

} 

'*  set  up  the  header  */ 
dataHead.info.type  = MT_RAW_DISP; 
dataHead.info.format  = MT_16_BIT; 
dataHead.info.num_ch  = 1 ; 

1*  convert  data  format  */ 

swab((char  *)&dataHead,  (char  *)&dataHead,  sizeof(MTRawDispMsg)); 
send  the  message  */ 

f (tcpOut->sendData((mt_samp  *)&dataHead,  sizeof(MTRawDispMsg))  !=  0)  { 
fprintf(stderr, "Error:  could  not  send  header  to  host\n"): 
exit(-l); 

} 

Figure  6-3.  Initiating  a message. 
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sample  will  be  a 16  bit  two’s  complement  integer.  The  number  of  data  channels  is  set  to 
one.  The  data  format  is  converted  into  the  globally  agreed  upon  format,  and  sent  to  the 
destination  by  means  of  the  sendData  command. 

Adding  a Data  Server 

The  network  server  maintains  a list  of  known  message  formats  and  the  correspond- 
ing data  server.  The  format  of  the  list  was  presented  in  figure  4-4.  When  adding  a new  data 
server  to  the  system,  a unique  number  and  class  name  need  to  be  chosen.  This  information 
will  be  added  to  the  list  in  figure  4-4.  The  network  server  listens  to  the  network  for  a con- 
nection request.  When  a connection  is  accepted,  a new  thread  is  spawned  to  handle  the 
communication.  This  thread  will  read  the  first  two  bytes  from  the  new  connection  and  then 
call  a registration  function  that  will  instantiate  a new  object  according  to  figure  4-4.  The 
thread  will  then  proceed  to  read  the  data  from  the  network  and  place  it  into  the  buffer.  The 
initial  portion  of  this  data  will  be  the  message  header.  Since  the  new  object  knows  about 
the  message  format,  it  will  parse  this  information  and  store  it.  This  information  will  be 
used  later  for  selecting  and  configuring  a data  view. 

Due  to  a limitation  of  the  window  system  on  the  NeXT  workstation,  display  func- 
tions can  not  be  multi-threaded.  There  are  two  reasons  for  this.  First,  the  window  system 
was  not  written  to  allow  for  re-entrant  code.  This  prevents  multiple  threads  from  executing 
the  same  function.  The  second  reason  lies  in  how  display  is  performed.  The  NeXT  imple- 
ments a display  postscript  language,  which  means  that  all  display  is  performed  by  using 
postscript  commands.  The  commands  are  interpreted  by  a postscript  server  task,  which 
expects  that  there  is  only  one  thread  per  application  task  that  will  request  display  func- 
tions. The  end  result  of  this  is  that  one  thread  is  allocated  in  the  supervision  software  that 
will  handle  display  to  all  views  and  input  from  keyboard  and  mouse. 

Part  of  the  process  of  the  dynamic  registration  of  new  data  servers  is  to  update  an 
internal  list  of  active  data  servers.  Data  servers  and  display  servers  are  objects,  and  a list  of 
active  objects  is  maintained  for  each.  When  a new  data  server  is  detected,  its  message  type 
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is  queried  and  then  compared  against  a list  of  display  servers.  A display  server  is  selected 
from  this  list  and  activated.  The  data  server  is  then  attached  to  this  object.  Active  display 
servers  then  take  turns  at  updating  their  portion  of  the  screen. 

Results 

Figure  6-1  shows  a snap  shot  of  the  computer  screen  during  an  on-line  test.  The  dis- 
placement view  shows  the  magnitude  of  the  average  displacement  during  the  transition 
through  entry.  During  this  test,  the  raw  displacement  signal  was  captured.  The  results  of 
the  capture  are  shown  in  the  Data  Capture  view. 

In  the  following  chapter  a tool  for  interactive  data  analysis  and  algorithm  develop- 
ment will  be  presented.  This  tool  coupled  with  the  ability  of  the  supervision  system  to 
integrate  a detection  system  into  a signal  monitoring  and  capture  facility  extend  the  dis- 
tributed supervision  system  from  an  alarm  system  to  a research  and  development  tool. 


CHAPTER  7 

OFF-LINE  ANALYSIS  SYSTEM 
Necessity  of  Off-Line  Analysis 

An  off-line  analysis  tool  was  developed  to  aid  in  understanding  the  dynamics  of  the 
data  and  to  validate  the  signal  processing  algorithms.  Algorithm  design  is  simplified  by 
providing  an  interactive  data  analysis  tool  in  the  algorithm  design  process.  The  data  uti- 
lized by  this  tool  is  identical  to  that  encountered  in  real-time  operations.  This  off-line  tool 
is  organized  such  that  algorithms  designed  within  its  framework  will  operate  in  real-time. 
That  is,  they  are  required  to  process  data  one  sample  at  a time.  The  difference  from  an 
actual  real-time  implementation  is  that  there  is  a set  of  buffers  that  maintain  a record  of 
intermediate  results  as  well  as  the  final  result.  On  completion  of  data  processing,  all  buff- 
ers are  available  for  inspection.  By  maintaining  real  time  implementation  guidelines,  the 
resulting  algorithm  requires  little  modification  for  the  actual  implementation. 

The  importance  of  the  off  line  system  extends  past  its  significance  in  validating 
algorithms  for  real-time  implementation.  It  also  plays  an  important  role  in  conjunction 
with  the  on-line  supervision  system.  The  supervision  system  has  the  function  of  in-process 
monitoring.  In  this  capacity  it  will  stop  the  machine  after  tool  failure.  However,  in  a 
research  environment  there  is  another  important  function.  The  supervision  system  can 
capture  data  and  pass  it  to  an  off-line  system.  Here,  the  researcher  can  inspect  the  data  in 
greater  detail.  Information  gained  from  this  inspection  can  be  used  to  detect  errors  in  the 
current  algorithms,  to  make  improvements  to  the  current  algorithms,  or  to  gather  knowl- 
edge for  implementing  future  algorithms. 
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Features  of  an  Off-Line  System 

With  a large  collection  of  data  and  the  attributes  of  the  data,  intensive  offline  testing 
of  machine  tool  monitoring  algorithms  can  be  undertaken.  Therefore,  the  data  analysis 
system  is  designed  to  manage  a data  base  of  milling  machine  vibration  data.  However,  the 
conditions  under  which  the  data  is  collected  need  to  be  maintained.  Having  to  discard  past 
data  records  due  to  inadequate  documentation  of  the  machining  parameters  was  a common 
occurrence.  To  avoid  loosing  valuable  data,  a data  base  is  incorporated  into  the  system  to 
store  information  about  the  data.  The  present  system  maintains  the  following  parameters. 

• Samples/Rev 

• Number  of  teeth 

• RPM 

• Feed  per  tooth 

• Type  of  milling:  up  or  down 

• Tool  status:  i.e.  broken 

• Workpiece  material 

• Axial  depth 

• Radial  immersion 

Information  is  stored  in  two  forms.  The  first  form  uses  a structured  data  field  format. 
This  allows  automatic  integration  of  parameter  information  into  the  program.  But,  all 
information  is  not  easily  classified.  For  information  of  this  category,  a loose  structured  text 

file  is  used.  This  provides  a loose  format  for  the  operator  to  describe  characteristics  of  the 
machine  operation. 

Such  information  that  falls  within  this  category  are: 

• Force  model  constants  (Kc,  rb  r2,  and  h*) 

• Probe  calibration 

• Tool  geometry 

• Workpiece  geometry 

• Tool  path 

• Variations  in  feed  and  depth 

• Other  information  deemed  pertinent  to  analysis. 

Algorithm  Development  Cycle 


The  analysis  tool  follows  a cycle  shown  in  figure  7-1.  The  first  step  is  to  inspect  the 
raw  data  to  identify  key  features  and  possible  algorithmic  solutions.  After  obtaining  a 
basic  understanding  of  the  data  and  choosing  methods  of  feature  extraction,  algorithms 
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Inspect  Data 

Develop  Code 

_Z* 

Inspect  Results 

* 4 

Modify  Code 

r 

Finished  Product 

Figure  7-1.  Algorithm  development  cycle. 

can  be  developed.  The  analysis  tool  will  process  and  display  the  data  according  to  the 
algorithm,  and  the  cycle  of  modify-code  and  inspect-data  can  begin.  This  cycle  ends  when 
results  are  satisfactory,  at  which  time  the  code  is  ready  for  real  time  testing. 

User  Interface 

The  interface  was  designed  based  on  the  User  Interface  Guidelines  of  the  NeXTStep 
window  system  [69],  A review  of  this  book  will  provide  a good  introduction  to  the  princi- 
ples of  using  the  mouse  to  navigate  through  a program.  The  tool  is  started  by  executing  the 
TB  program. 

The  Tool  Breakage  Parameters  window  (figure  7-2)  is  displayed  upon  running  the 
program.  There  are  two  sets  of  data  fields  contained  within  this  window.  A parameter 
input  window  is  used  to  specify  options  for  data  processing.  The  Parameters  box  contains 
the  user  definable  options.  It  is  here  that  the  user  sets  attributes  of  data  and  parameters  for 
signal  processing.  These  include  the  number  of  teeth  on  the  tool,  the  number  of  samples 
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Figure  7-2.  Parameter  input  window. 


per  revolution  (synchronous  sampling),  the  length  of  the  median  filter,  the  length  of  the 
averaging  window  for  estimating  the  average  displacement,  the  memory  depth  for  the 
RORPA  filter,  a minimum  allowable  threshold,  the  ratio  of  average  displacement  to  dam- 
age symptom  for  feature  detection,  and  the  number  of  damage  features  required  before 
deciding  that  the  tool  is  broken.  The  Dependent  Parameters  displays  data  dependent  val- 
ues calculated  by  the  system.  These  include  some  global  characteristics  of  the  signal  and 
the  processing  routines,  such  as  the  average  and  power  of  the  raw  data  during  idle  milling, 
the  length  of  the  RORPA  filter  window,  and  the  delay  required  to  align  the  damage  symp- 
toms with  the  average  displacement. 

Selecting  Input  Data 

By  selecting  the  File  submenu  from  the  main  menu,  and  then  selecting  open  data  file 
(figure  7-3),  the  input  data  source  can  be  selected.  The  user  will  be  asked  to  first  select  the 
X channel  file,  and  then  the  Y channel  file.  The  notion  of  the  X and  Y channels  are  histori- 
cal. The  requirement  is  that  the  two  channels  contain  recordings  from  orthogonal  axis. 
Data  files  are  selected  through  a file  browser  interface.  The  browser  interface  is  shown  in 
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Figure  7-3.  Initiating  data  load. 
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Figure  7-4.  Selecting  input  data. 


figure  7-4.  The  browser  presents  two  levels  of  the  file  system  hierarchy.  The  user  can  nav- 
igate through  the  file  system,  select  the  desired  file,  and  press  OK.  After  the  X and  Y chan- 
nel files  are  selected,  data  analysis  can  begin.  By  pressing  the  Do  TB  button  in  the  Tool 
Breakage  Parameters  window,  the  data  will  be  processed  and  the  results  presented. 


Machining  Info 

After  selecting  a data  file,  the  milling  data  base  can  be  queried  for  attributes  of  the 
data.  Figure  7-5  shows  a typical  Machining  Info  window.  From  this  example,  we  can 
immediately  see  that  the  data  was  recorded  at  72  samples  per  revolution  and  that  the  tool 
was  in  good  condition. 
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Figure  7-5.  Machining  data  window. 


Figure  7-6.  Example  of  data  display. 


Data  Display 

The  main  feature  is  the  interactive  data  display.  Figure  7-6  shows  a typical  data  dis- 
play. Several  signals  are  available  for  viewing.  These  signals  represent  intermediate  results 
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Figure  7-7.  Display  setup. 
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Figure  7-8.  Selecting  display  setup. 


as  well  as  the  final  result  of  the  signal  processing.  The  format  of  signal  display  is  adjusted 
through  the  format  option  in  the  tools  submenu.  This  Display  Setup  (figure  7-7)  window 
allows  the  selection  of  display  signals,  amplitude  scale  adjustment,  and  selection  of  an 
overlay  signal.  Pop-up  buttons  are  used  to  select  the  display  channel.  By  pressing  the  left 
mouse  button  (figure  7-8),  a list  of  available  signals  will  be  presented.  An  item  is  selected 
from  the  list  and  the  mouse  button  is  released.  Once  a signal  is  selected,  then  the  user  has 

the  option  of  setting  the  signal  as  displayable,  setting  the  amplitude  scale,  and  selecting  an 
overlay  signal. 


Examining  Data 

The  use  of  the  mouse  is  key  to  examining  the  data.  A system  of  point  and  click  is 
used.  A section  of  data  is  selected  by  a scheme  of  moving  the  cursor  to  a starting  location. 
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Zoom  Cursor 

Inspection  Cursor 
Figure  7-9.  Tool  box. 


Figure  7-10.  Signal  info  window. 


pressing  the  left  mouse  button,  dragging  to  the  end  point,  and  releasing  the  button.  Since 
there  are  several  desirable  functions  for  the  mouse,  a tool  box  (figure  7-9)  is  available  for 
selecting  a desired  function.  This  tool  box  is  available  by  selecting  the  icons  option  in  the 
tools  submenu.  The  zoom  cursor  is  the  default,  and  it  is  used  to  select  a portion  of  signal 
for  close  visual  inspection.  The  inspect  cursor  also  selects  a segment  of  data  for  inspec- 
tion, but  instead  of  changing  the  visual  display,  attributes  of  the  data  are  presented  in  the 
signal  info  window. 

Signal  info 

This  option  displays  user  selected  information  about  the  current  data  file.  When  a 
portion  of  the  data  is  selected,  the  Signal  Info  window  (figure  7-10)  displays  information 
about  that  data  segment.  The  following  example  will  explain  this  feature.  In  this  example 
the  output  from  an  averaging  module  was  selected.  The  file  index  was  2144,  and  the  length 
of  selection  was  1889  samples  long.  Four  values  are  calculated  from  this  data  segment. 
These  are  the  minimum,  maximum,  average,  and  power  of  the  signal  segment. 


108 


Figure  7-12.  Damage  symptom  window. 


Damage  symptoms 

Selecting  Damage  Symptoms  from  the  file  menu  display  the  Damage  Symptoms  win- 
dow. This  window  shows  the  result  of  the  tool  damage  detector  module.  Figure  7-11  pre- 
sents a segment  from  a broken  tool.  This  data  was  taken  for  an  8 tooth  face  mill  with  one 
tooth  missing.  Below  is  the  output  of  the  Damage  Symptoms  (figure  7-12)  window.  These 
numbers  have  relevance  within  the  context  of  the  damage  detector  routine,  and  are  useful 
for  debugging.  For  example,  the  line  “1  matches  at  354:  fCount=15”  represents  that  a 
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single  feature  was  found  at  index  354.  The  value  of  /Count  is  the  number  of  samples  that 
exceeded  the  damage  threshold.  For  this  example  there  are  8 teeth  and  120  samples  per 
revolution.  The  15  samples  (120/8  = 15)  correspond  to  one  tooth  period  of  the  missing 
tooth.  The  following  line  that  reads  “2  matches  at  359:  fCount=15”  represent  a second  fea- 
ture of  tooth  damage.  This  feature  represents  the  tooth  following  the  broken  tooth.  Since  it 
inherits  an  increased  chip  load,  its  force  is  increased.  These  two  lines  combine  to  represent 
the  characteristic  down-up  spike  feature  of  tool  breakage. 

Conclusions 

The  impact  of  this  tool  for  developing  the  code  for  tool  breakage  can  not  be  over- 
stated. It  aided  in  producing  code  that  is  robust  since  the  test  data  was  collected  from 
actual  machining. 

Its  significance  also  extended  into  the  on-line  testing.  The  on-line  system  was  con- 
figured to  maintain  a buffer  of  the  last  8192  samples  of  raw  data.  These  could  be  accessed 
manually  under  operator  control.  However,  having  these  data  automatically  grabbed  after 
fault  detection  aided  in  tracing  causes  for  false  positive  detections.  Also,  in  the  rare  occa- 
sion of  natural  tooth  breakage,  the  data  will  be  automatically  stored  to  disk. 


CHAPTER  8 
CONCLUSIONS 

Focus  of  Work 

The  primary  focus  of  this  dissertation  has  been  model  development,  implementa- 
tion, and  validation.  Throughout  this  work  various  important  areas  of  manufacturing  have 
been  examined  with  an  end  goal  of  supervision  for  machine  tools,  where  supervision 
entails  monitoring  the  state  of  the  machine  so  that  changes  in  environment  can  be  accom- 
modated. State  information  of  particular  interest  was  the  status  for  the  tool,  which  led  to 
the  inclusion  of  a detector  for  tool  breakage.  Analysis  of  this  particular  system  empha- 
sized the  need  for  accurate  milling  models. 

Multi-Tooth  Milling 

Analysis  of  milling  force  models  began  with  the  current  usable  model  of  tooth  force. 
It  was  not  an  exact  physical  model  of  metal  cutting,  but  was  a usable  model  that  relied  on 
average  values  for  parameters.  Chapter  two  introduced  this  model  and  then  proceeded  to 
develop  an  extension  that  described  the  effect  of  multi-tooth  milling.  This  was  important 
because  this  is  a common  operating  mode.  Multi-tooth  milling  was  presented  as  a linear 
combination  of  single  tooth  force  signals.  A key  result  was  that  in  multi-tooth  milling,  the 
features  of  the  single  tooth  signal  will  be  aliased.  The  method  by  which  this  occurs  was 
discussed,  and  observable  features  were  presented. 

The  single  tooth  force  signal  has  four  parameters  that  have  been  defined  as  constants 
for  a particular  workpiece/tool  combination.  Chapter  two  concluded  with  a discussion  on 
how  these  parameters  can  be  extracted  from  test  cuts.  The  chosen  method  for  accomplish- 
ing this  goal  was  based  on  a weighted  least  squares  solution.  The  agreement  between  sim- 
ulation and  real  data  was  presented. 
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Tool  Breakage 

A description  of  tool  breakage  and  methods  for  its  detection  were  described  in  chap 
ter  three.  These  discussions  relied  on  the  models  of  chapter  2.  With  a multi-tooth  force 
model,  tool  breakage  could  be  investigated.  This  analysis  took  two  forms.  The  first 
approach  examined  the  breakage  transient.  An  extraction  routine  based  on  a revolution 
difference  was  used  to  extract  this  transient.  The  size  of  this  transient  was  then  compared 
with  extractable  physical  parameters  from  the  displacement  data,  which  included  the 
effect  of  radial  immetsion.  As  immersion  increases  damage  features  will  become  less 
prominent.  Although  it  is  anticipate  that  further  analysis  on  the  multi-tooth  force  model 
will  reveal  a method  of  determining  the  immersion,  the  present  system  relied  on  the  fea- 
ture extraction  and  the  syntactic  feature  interpretation  to  provide  the  necessary  signal-to- 
noise  ratio.  Detection  of  the  breakage  transient  concluded  with  actual  records  of  “induced- 

tooth  breakage.  These  records  were  successfully  detected  by  setting  the  feature  threshold 
for  the  worst-case  full  immersion  cut. 

A second  tool  status  problem  was  discussed.  This  problem  involved  starting  a cut 
with  a broken  tool.  The  revolution  difference  suffered  since  it  focused  on  the  transient  that 
occurs  when  a tooth  breaks.  This  algorithm  shifted  its  emphasis  from  transient  detection  to 
detection  of  a missing  tooth.  The  missing  tooth  does  not  contribute  force  to  the  multi-tooth 
force  signal.  It  was  also  shown  that  the  tooth  following  the  missing  tooth  produced  higher 
than  average  force  since  it  inherited  the  job  of  two  teeth.  This  led  to  the  choice  of  the  tran- 
sition from  the  missing  tooth  to  the  following  tooth  as  the  primary  feature.  This  feature  is 
emphasized  though  a tooth-period  difference.  Although  tool  throw  will  produce  large 
force  variations,  it  does  not  produce  the  large  single  tooth  period  transition.  Revolution 
differencing  was  included  to  remove  runout. 

Since  missing  tooth  tests  are  easy  to  perform  (performing  tooth  breakage  is  not), 

117  test  records  were  used  for  verification.  There  were  0%  false  negative  errors  and  5% 
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false  positive  errors.  Although  this  system  could  function  for  detecting  tool  breakage,  it 
introduced  a delay  of  one  revolution  over  that  of  the  transient  detector. 

Supervision 

Machine  tool  supetvision  was  modeled  as  a loosely-coupled  distributed  system.  A 
loosely-coupled  system  is  a cohesive  collection  of  computets  capable  of  autonomous 
operation.  The  only  requirement  for  each  computer  was  that  it  be  capable  of  communica- 
tion through  TCP/IP  protocol  over  the  ethemet  computer  network.  This  heterogeneous 
system  allowed  for  each  computer  to  be  independently  specified  in  its  computational 
capacity,  as  well  as  a variable  number  of  computers.  This  allowed  for  easy  extensibility  of 
the  system  to  include  new  methods  of  machine  tool  control. 

Flexibility  was  obtained  by  using  a design  method  based  on  objects  and  threads. 
Objects  served  several  purposes.  Encapsulation  was  used  to  separate  distinct  functions 
such  as  network  communication,  data  display,  and  dam  processing.  If  the  system  is  prop- 
erly encapsulated,  then  one  function  can  be  modified  or  replaced  without  modification  to 
other  functions.  For  example,  the  data  server  objects  could  be  modified  to  accommodate  a 
new  network  system  without  modifying  the  display  and  dam  processing  objects. 

Inheritance  was  used  heavily  in  the  communicatton  model.  There  were  several  types 
of  network  messages.  However,  there  were  common  features  among  the  whole  group,  and 
many  subgroups  of  these  messages  shared  features.  By  identifying  the  common  features,  a 
hierarchy  was  specified  so  that  common  features  were  contained  within  a single  definition. 
Since  it  is  anticipated  that  new  message  types  will  be  required  and  that  these  types  will 
share  common  features  with  existing  types,  the  new  methods  can  directly  inherit  the  com- 
mon  features  and  only  implement  the  new,  additional  features. 

A partial  ordering  was  introduced  through  threads.  A thread  is  a totally  order  set  of 
events  defined  by  a programmer.  The  distributed  system  was  classified  through  this  analy- 
sis. Each  computational  engine  has  at  least  one  thread  of  control.  However,  many  comput- 
ers have  multiple  threads  as  an  easy  means  of  scheduling  events.  Multiple  threads 
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provided  an  efficient  method  of  dynamically  allocating  tasks.  There  efficiency  was 
obtained  by  their  ability  to  steal  CPU  cycles  only  when  necessary. 

Data  server  objects  were  used  to  implement  a message  passing  protocol.  Messages 

are  flexible  in  nature.  The  only  requirement  imposed  was  that  each  message  began  with  a 

type  identifier  that  was  then  used  to  instantiate  a data  server.  Data  servers  were  easily 

added  to  the  supervision  system,  and  were  responsible  for  understanding  the  message  for- 
mat. 

Since  the  CNC  was  a necessary  component  of  a supervision  system,  considerable 
detail  was  expended  on  this  topic.  This  was  not  a general  discussion,  but  focused  on  a par- 
ticular CNC,  the  AI  Flexmate.  The  job  of  providing  external  control  to  the  CNC  was 
addressed  early  in  the  project  through  collaboration  with  students  of  the  Machine  Tool 

Laboratory  and  the  manufacturer.  It  was  the  critical  first  step  in  implementing  a supervi- 
sion system  for  machine  tools. 

An  interface  was  developed  similar  to  the  ISO  OSI  model.  That  is,  a flexible  inter- 
face was  developed  and  tested  to  provide  reliable  communications.  This  basic  model  was 
based  on  the  remote  procedure  call  (RPC)  interface  common  to  workstations.  The  RPC 
structure  was  not  unlike  the  messaging  protocol  developed  for  the  supervision  system  in 
that  knowledge  of  low-level  hardware  was  not  visible  to  the  programmer.  All  external 
CNC  functions  were  built  using  the  RPC  interface. 

In  chapter  six  the  pieces  for  the  supervision  system  were  assembled.  Details  of  net- 
work communication  were  given  through  examples  to  show  how  connections  were  made 
and  data  was  transferred.  Actual  output  from  successful  testing  was  presented.  Chapter 
seven  completed  the  implementation  by  describing  a tool  by  which  displacement  data 
could  be  inspected.  This  tool  was  developed  so  that  signal  processing  routines  could  be 
tested  with  recorded  data.  It  was  also  used  in  debugging  the  on-line  tool  breakage  system. 
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Programs 

The  programs  written  for  verification  of  this  work  are  available  in  an  internal  report 
from  the  Computational  Neuroengineering  Laboratory.  The  force  models  presented  in 
chapter  2 were  implemented  in  Matlab  for  testing  and  verification.  These  include  the  fou- 
rier  spectrum  in  continuous  time  (Fn,  equation  2-12),  the  single  tooth  force  in  discrete 
time  (fp(n),  equation  2-17),  and  the  DFT  of  the  single  tooth  force  (fp(k),  equation  2-18). 
Also  included  are  a method  of  simulating  the  breakage  feature  following  a revolution  dif- 
ference and  an  implementation  of  the  method  for  finding  the  machining  constants  (Ks,  rh 
r2,  and  h*). 

The  code  listing  for  the  software  interface  of  the  Flexmate  CNC  can  be  found  in  the 
Ph.D.  dissertation  by  Lindsay  Wells  [66].  The  remainder  of  the  program  listings  are  avail- 
able in  the  internal  report.  The  code  listings  for  the  supervision  system  is  partitioned  into 
three  main  groups.  These  are  the  code  listings  for  the  NeXT,  the  PC/AT,  and  the  DSP 
56001 . Each  of  these  is  prefaced  by  a brief  description  of  files  and  is  further  partitioned 
into  functional  groups  such  as  event  management,  network  interface,  data  servers,  and  dis- 
play servers.  The  listing  for  the  off-line  analysis  tool  is  presented  in  the  same  fashion.  The 
programs  were  implemented  using  Objective  C on  the  NeXT,  C++  on  the  PC/AT,  and 
assembly  for  the  DSP. 


Future  Work 

Further  work  on  the  force  model  would  include  parameter  identification.  Extraction 
of  radial  immersion  would  allow  for  finer  control  of  the  tooth  breakage  threshold.  It  would 
also  allow  for  adjustments  in  the  expected  tooth  breakage  signature.  Knowledge  of  the 
radial  immersion  would  allow  for  the  decomposition  of  the  multi-tooth  signal  into  the 
individual  single  tooth  forces,  or  it  may  be  that  the  decomposition  will  lead  to  extracting 
the  radial  immersion  Additional  work  would  also  include  expanding  the  force  models  to 
include  operating  modes  other  that  steady  state.  These  modes  would  include  variations  in 
speed  and  depths  of  cut. 


115 


A basic  user  interface  was  implemented  for  the  supervision  system.  A future  system 
would  include  the  standard  features  of  the  CNC  operator  console  so  that  there  would  only 
be  one  operator  station  for  the  machine.  Additional  “non-operator”  consoles  could  be 
added  for  system  monitoring  from  remote  sites.  Future  enhancements  would  also  include 
incorporating  additional  detectors  such  as  chatter  detection  into  the  system. 

The  set  of  display  servers  could  be  expanded  beyond  the  current  set  of  temporal  dis- 
plays to  include  digital  and  analog  gauges.  At  present,  the  average  force  is  presented  with 
a temporal  display  that  provides  the  current  and  past  values  of  the  average  force.  However, 
if  it  is  only  desired  to  maintain  the  current  force  value,  then  a simpler  display  such  as  a 
simulated  analog  gauge  could  provide  this  information.  Such  enhancements  were  envi- 
sioned, and  was  one  of  the  decisive  factors  in  choosing  an  object  oriented  design.  Since 
display  functions  were  encapsulated  through  object  oriented  design,  modifying  or  adding 
presentation  forms  will  not  involve  modifying  the  remainder  of  the  system  code. 
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